In Conversation with Joe Justice about agile hardware development
Sohrab: Hey, everyone. Welcome back to our next Agile Insights conversation series. Today, I'm hosting one of my friends, Joe Justice, who's also a certified scrum trainer but does so much more amazing stuff. I will give Joe some time to introduce himself at the very beginning. In addition to getting to know Joe, we're going to talk about building hardware in an agile manner. He has some significant experience in that space, doesn't mean that he doesn't know how to build software, I think that's where he got started, but he also has a lot of hardware experience.
[00:01:52]
Then I want to go through something that Marty Cagan does in his books where he compares the best and the rest, and I want Joe to give us his take on agile product development, especially in the hardware, maybe even, especially, in the automotive space. And based on that, where we identify those big differences, I want to evaluate with Joe together what are the things that organizations that are currently part of the rest and not part of the best can do in order to become part of the best.
[00:02:21]
So, Joe, it's a real, real honor to host you again (You can see the other sessions with Joe here and here). Thank you so much for donating your time and your experience. I'm so thrilled, so excited, to go through this conversation. Welcome to the show.
[00:02:35]
Joe: It is super fun for me to be here. Everyone, I'm not sure if you know, Sohrab and I went to Bosch years ago to work on agile hardware and software with the teams there. Sohrab and I have done remote and in-person collaborations for years now. And I'm lucky enough to reconnect here as part of this program. Hi, I'm Joe Justice. I have an office in Tokyo and an office in Hawaii. Right now, I'm in Seattle, Washington. So this isn't my office. This is actually the home gym where I used to live, the old house that's getting put up for rent I think soon. I'm visiting here, playing with my kids. And made time to talk agile hardware and agile business and agile software with Sohrab. It's my honor and privilege to be here.
[00:03:18]
Sohrab: Cool. Joe, let's just get started. I mean, you already gave a brief introduction, but that was very brief. Share a bit more about yourself and the journey that you've been through, especially in the past, let's say, 8 to 10 years, which I think will also show people that haven't met you yet, I mean, there are already a lot of talks from you on YouTube, but I'm sure there are people that haven't met you yet, to understand where all your thoughts, where all your insights come from.
[00:03:45]
Joe: You're very kind to ask. Okay. I'm not sure if everyone's really interested, but I'll try. I'll do my best. I'm Joe Justice. I'm from a little farming town in the middle of the U.S.A., and I went to not a famous college. And then my first real job out of college was one of the first companies trying agile methods. I was handed, right at the start of my work, one of the first books published on agile and on scrum, and I was asked, "Please read this. We'll run this way."
[00:04:18]
With that little company...actually, the company was pretty big. What that company did, my first serious job after college, what they did is they wrote software for the U.S. government, the United States government, primarily tax filing software for the government, not for consumers. And my job was to create the first e-filing system, the first online file-and-upload system, for the U.S. government as part of their pension program, and it was an agile project. I was a team of one, which wasn't the right way, and they knew it too. They were trying to figure it out. We were all new. But we did do many of the practices that became much more normal about agile later, and it was successful. As far as I know, if you're getting a pension guaranteed by the U.S. government, say, you're a large company, like an airline company, you're still uploading all your documents through the software I wrote way back then. I think it's still live. And I learned a little bit about agile and a lot about real work and a little bit about how government works.
[00:05:18]
And that attracted the attention of Accenture, the consulting company. And Accenture had just made a joint venture with Microsoft called Avanade, and it was a consulting arm to do software development, software management, software ideation, and software ideas, and a little bit of hardware but almost all software, only using Microsoft products on behalf of Accenture. And they hired me. And that's where I really started to learn a lot. Again, I'm from little farming town, and I didn't go to that famous school, although they had a good program. I graduated in computer science. I learned a lot through consulting with this group.
[00:06:00]
I worked in some oil companies, writing software to help plan how oil wells go through their whole life cycle, basically, project managing oil wells, and that was agile, interestingly, agile energy, agile oil extraction, which was pretty early for agile, especially in energy. And then automotive manufacturing and automotive legalization was a project I worked on, and that's where I learned a lot. Then, I was recruited, by name, to be a scrum master for Bill Gates, and that was a turning point that was a significant change in my life. Apparently, I was good at what I was doing. I'd been noticed and recognized. And I started a car company called Wikispeed.
[00:06:46]
I started Wikispeed in 2006. I used agile operations only, because my degree was not in project management, it was in software. And then I had done all that software with agile. I didn't know another project management. So Wikispeed started as an agile company. So our finances, our tax filings, when we had to do legal audits, it was all agile. Of course, our software was, too, and our supply chain management and our manufacturing. And it worked. We set four world records with this tiny, little automotive manufacturing company. I was doing that company at nights and on weekends while working for Bill Gates. So during the day, I'm at the Bill and Melinda Gates Foundation, and at nights and on weekends, I'm running a tiny, little car company, which ended up being very successful.
[00:07:39]
Then, I went to consult to leadership teams at Amazon and to Blue Origin, also. Jeff Bezos was CEO of both at the time, and I learned a lot from Jeff's style, Jeff Bezos's style. And then, ultimately, I joined Tesla as a full-time employee in 2020. I'd consulted to Tesla since 2010, I'd set up the first agile trainings in Tesla in 2016, and then I joined as a full-time employee in 2020. And I'm really, really proud of this part. I was told I'm the best interview they'd ever had at Tesla. So I thought, "Awesome. I'm going to be, like, the grand high agile king, or something, of Tesla." I was hired as a manufacturing associate. So I come in, and I have no office, but I realized, no one has an office. I realized how flat the company was. Like, no one has an office. But I was like, "Where are the offices? Like, there aren't any." And, like, I go right in, and they're like, "The elevator's jammed. Let's fix it." I'm like, "I've never fixed an elevator." And they're like, "We're going to do it." I'm like, "Okay." And we go right into work.
[00:08:52]
And I did set up some really cool agile things in Tesla. I'm proud of it. But let me be very clear, far and away, the majority was me learning. Everything I'd done before, all the cool agile stuff that I thought I had done, was really junior compared to, really silly, compared to what I'd seen once I worked for Elon Musk. Most of my time there, I actually want to give credit back, that was me learning. I did install some cool agile stuff and level up the Musk companies. I did. I'm super proud of it. That was the minority. Far and away, it was me being blown away and taking notes in a journal every morning and every night. I'd written a book before I joined Tesla. I updated it after I retired and wrote, "Ignore everything I wrote in chapter 1 through 20. Here, chapter 21 is what I think you really need to know now that I worked for Elon." It was shockingly quick, and I think we'll talk more about that in the maybe best versus the rest. And I'll give my opinion.
[00:09:59]
So I'm Joe. I'm a very normal person, with a very normal background, and then I had an interesting opportunity to learn in consulting and then really got thrown into what life, at high speed, in a very fun way, can be working for Elon. And now, I retired in 2020. I bought a little condo in Hawaii. I had enough money that if I lived kind of simply, I could just live. And I got bored. I realized I am a workaholic, so I started the Agile Business Institute, actually, just before, and then I rebooted it. I turned it on. And I work 12 hours a day, 7 days a week, doing online trainings, because I love it, because it's actually really fun. So that's my excuse that I get to hang out with very skilled agilists, like Sohrab.
[00:10:45]
What does agile development even mean in the hardware space?
Sohrab: Yeah, So I'm amazed that you just figured out that you are a workaholic after you were able to retire, because I could have told you that back then when we worked together at Bosch that you are a workaholic and that you will be bored if you don't have something interesting to do. But no, jokes aside, Joe, thanks for giving this introduction. I think this helps also a lot of people when they see this to put things into perspective, right? The journey that you've been through is...I'm not going to say it's not normal because that might sound, in any way, bad. I don't mean it that way. It's very unique. Not a lot of people get the opportunity to work with these kinds of world-class leaders, world-class innovators.
[00:11:31]
And what I find interesting is that you took away a ton of insights. And knowing you, you're a naturally curious person, and I can imagine that when you were at Tesla or any of the other organizations that you mentioned that you were just absorbing this information, this knowledge, and how they're working. And that's one of the reasons I'm so excited to go through this interview with you.
[00:11:55]
Now, one of the things that I want to kick this off quite, quite easily, and I'm sure you've talked about this several times, you and I had exchanges about this, is that when we look at the world of hardware development, and especially, looking at Germany, it's a country where hardware is at the core, right? They don't have that many big software companies. SAP, probably the only one. Now, another one, Celonis, coming up. But it's mainly hardware, both at large scale, if we look at the automotive industry, if you look at the energy industry, like Siemens Energy, healthcare industry, but also at a smaller scale when we look at all the SMEs, the hidden champions, that many of them come out of Germany, they build hardware products.
[00:12:38]
And when I interact with some of these organizations, there's always this question, "Okay. We get it. In the software world, you can do this incremental, iterative approach, and you can learn, and all of that. But we're building the real stuff, right? And you can't apply these techniques. You need to know up front what you really want to build, and then you need to execute according to the traditional approach, the milestones that we set out." What do you say to them?
[00:13:10]
Joe: Yeah. People were really freaked out when, for example, Tesla, I don't mean to only talk about Elon Musk, but it was very powerful learning experience for me, people in Germany were freaked out when Tesla started building Giga Brandenburg, Giga Berlin. And when the building was waiting for permits, they built it anyway. The vast majority of the construction was made before the permit was approved. So in the traditional milestone, as you apply for the permit, you wait for the permit to be approved, which can take several years for a large project in the EU, and then you begin construction in phases.
[00:13:51]
Well, Tesla realized, "The worst thing that happens if our permit's not approved is we have to return the land to its previous condition. We're allowed to start construction. We just might have to return the land to the previous condition." So the agile mindset is pace of innovation is the only thing that matters in the long run. "So, at least, we'll have learned how to do all this construction and who to work with and how even if we then have to do it a second time. So the second time will be even better."
[00:14:21]
So they started building the day they sent the permit application in, cleared the land, replanted the trees, moved the silkbacks, snakes, all these things, measured the water supply, started building the factory and modules. So already, there are several years ahead on the manufacturing timeline. Everyone else is like, "This is such a bad idea," right? Now, it gets better. As they're building...
[00:14:46]
Sohrab: So they were well aware of the risk, right? They were well aware of the risk. Okay. Now, it gets better.
[00:14:51]
Joe: Fully, fully accepted the risk. Then, as soon as a roof is put on with some level of solar, already, there's tools going inside and people working, designing new product, and building new product. There's not even walls on the buildings yet, right? They're definitely not approved for any type of use other than prototyping and setting machinery. Well, as the machinery is being evaluated and set, it's also being used, as it should be, to dial in the machinery. And most companies make...
[00:15:22]
Sohrab: Just one second, Joe. So the MVP on the building is there is a roof, there is some solar on it, we move some machinery in, we can get production started, we don't even need walls.
[00:15:38]
Joe: Or a permit.
[00:15:39]
Sohrab: Or a permit. I mean, permit, okay. But that's the definition of an MVP, in that case. Build the outcome, we can get production started. Is that correct?
[00:15:50]
Joe: Exactly correct. Exactly correct.
[00:15:52]
Sohrab: I will interrupt you from time to time, because I just want to make it, like, graspable for the people watching this at some point in time.
[00:15:59]
Joe: It is absurd. Like, it's that far...in a way, it makes perfect sense, but it's hard to even see it, because it's so far outside what we'd normally consider. Most companies make 1, 2, 10, maybe 200 pre-production units to test how things fit together of the design that's already settled, the design that's already set. What Giga Brandenburg did, Giga Berlin, is they improved the design based on the new machinery, because it's just arrived, it's being installed now, and it's great German machinery, all over the world, but also including great German machinery. So they're improving the design to match the toolset they have and making pre-production units. Well, they never stop. They never stop designing, they never stop making pre-production units, and they make them as fast as they can.
[00:16:50]
What happened is there were several thousand, Tesla model-wise, and they're all different. They have different experiments to make the car better in this massive holding facility by the time the building finally gets its permit. None of those cars can be sold. They're all pre-production units. So the next car made does get type approval and is sold, the first made in Germany Tesla Model Y. And some of you saw, in September, the Tesla Model Y was the most sold car in all of Germany of all type. Every BMW, every Daimler was less. And it was also measured to be the safest by the Euro NCAP. So the safest car in the world is the Europe-made Tesla Model Y, according to the Euro NCAP. So it worked. The cars they made were very high quality and the bestselling car in all of Europe, last month, interestingly.
[00:17:41]
So what happens to those, I think it was 6,000, pre-production cars? Well, the EU government said, "You know, if those cars do pass testing, I guess it's okay for them to be sold." They were all sold. So what happened is they made this huge bet. They buy the land, they apply for a permit, they just start building. They enter production, they enter design, they just start building. Eventually, the paperwork did clear. They're already two years ahead.
[00:18:09]
Like, there's no milestones. There's no concept of milestones. It's, pace of innovation is the only thing that matters in the long run, and go as fast as you can. Waiting is bad. Do not wait. And what that means is it is less efficient financially in the beginning. Because of the fast pace of iteration, now Tesla has the largest profit, the largest efficiency per vehicle sold, of anyone, anywhere in the world. So there has to be a period where you agree, "We're not about measuring the cost of that bolt. What we're maximizing for is pace of innovation and that we'll make it so our bolts are the least expensive, eventually." But to get there, pace of innovation is the only thing that matters.
[00:18:53]
The Pace of Innovation
Sohrab: Yeah. Now, I find this interesting because...let's take Tesla aside for a moment. For many years now, maybe even a decade or longer, Volkswagen and Toyota have been more or less selling the same amount of cars, roughly 10 million a year, but Toyota's market cap, in this period, was always more or less twice the one from Volkswagen. Why? Because with the same amount of cars, although the average price of a car is lower, they make higher profits. And that was always associated, at least in the articles that I read and the experience that I had, I worked with Toyota myself here in Cologne, was that they had lean implemented. And lean was continuously improving how you build stuff. Not necessarily what you build, but how you build things, and through that, get to higher quality and higher profit margins.
[00:19:50]
Now, what I'm hearing you saying about Tesla, and I saw those numbers as well, the profit margin that they have is insane. It's similar to, I think, Porsche or even higher than Porsche, closer to Ferrari, right, which would be a high-end premium automotive company. That is based on them taking the lean philosophy, now calling it agile, right, to the extreme, with the pace of innovation being the most important factor and not considering almost anything else, not being afraid of taking a bet, taking a risk, and through that, like, having those huge bets also succeeding, right? Because they have huge bets, but they have those bets, and they put it in a systematic approach to work. Can you talk about that a bit more?
[00:20:37]
Joe: You covered a lot of ground. Which part would you want to talk about more?
[00:20:42]
Sohrab: The pace of innovation and the systematic way that they approach having those huge bets.
[00:20:49]
Joe: Oh, sure. Okay. So some ground vocabulary, one very simple way for our audience to imagine lean, and no simple definition encompasses all of something as big and beautiful as lean, but to get us starting to think about it, one simple way for our audience to think about lean is use less stuff without frustrating your customer until it is very skillful at that, using less and less and less stuff without frustrating their customer. One simplification of agile, so, yes, this doesn't encompass all of agile, but one simplification of agile is reduce the cost to innovate, reduce the cost to make change. Now, these two things, if combined well, are super powerful.
[00:21:41]
There's some of lean that says, "Never change the design," because that's a waste. Well, that part conflicts with agile. There's some of lean that says, "Design to never change." That part conflicts with agile. But we can use lean, use less stuff without frustrating the customer, we can use lean to reduce the cost to make change. If making change, if innovation is an advantage, which agile would say yes, lean can be used to make agile come true in a frighteningly awesome way. And that is one way to summarize what some of these newer crops of really effective companies are doing, is the parts of lean that fit with changing as fast as you can, absolutely, as fast as you can.
[00:22:31]
Now, the systematic process inside a Musk company...let's go into the deep end. Let's do it. When you join the company, you're given 15 rules. It's called the Anti-Handbook Handbook. It's available online. You can read it. It's three and a half pages long. And that's it. That's your systematic process. You were told, "Don't break these rules. These rules are the simplest we got, but we think they're important. Go as fast as you can. You effectively have no manager. There's someone in a manager role to file legal reports or to take responsibility if something legally goes wrong, but they don't tell you what to do, and they don't review you or audit you." So they're not like you'd consider a manager. They're more, like, for legal compliance reasons, and who is in that role rotates more than one time a day. So it's really not, like, what most of us would consider a manager.
[00:23:27]
So you are on your own. This is the special forces of work. You are alone, and you recruit your platoon, your people around you, or you get recruited just from people saying, "Today, this looks important. Who's with me?" Like, really, that's what it is. There's not, like, a stand-up meeting or anything. There's none of that. You have these 15 rules, and you're told, "Go as fast as you can," and that is the process.
[00:23:51]
Now, that sounds absurd. You'd think there'd be milestones. You'd think there'd be funding meetings. You'd think there'd be coalitions of leaders to make big decisions. Like, should we use a structural battery pack or not? No, there's none of that. You just go. Now, with these 15 rules, it prevents total chaos. It's kind of like running an open space. If you had 100,000 people in a stadium and said, "Have a conference," you just get chaos. But if you have 100,000 people in a stadium and introduce the law of mobility and the 4 rules of open space, you get an open space. Well, Tesla has 15 rules, and they have 110,000 people, and they say, "Follow these 15 rules," and you get a car company. Like, it emerges. It self-emerges. There is no planning phase. It's not like that at all.
[00:24:41]
Now, to make it faster, a lot of questions people would frequently ask are put into apps on your phone. So you'd often ask a question like, "Can I take vacation?" You don't have a boss to ask, so you ask an app, and the app will say, "According to factory loading, it looks like that's fine." "According to factory loading, that's probably a problem. Please don't." And so the app answers it, and it answers it immediately. And the app's not perfect.
[00:25:07]
Sohrab: So HR is a bot.
[00:25:09]
Joe: Sorry?
[00:25:10]
Sohrab: HR is a bot.
[00:25:12]
Joe: Yes, HR is a bot. There's plenty of humans too to support you with special legal requests, especially in HR, but most questions we would wait for an answer are asked by, yeah, an app, including hardware design decisions, what would often be thought of as a milestone, "Should we use this battery diameter or that battery diameter?" That's a piece of software that answers that. That's not, like, a battery lead making that decision. It's either all apps.
[00:25:44]
Sohrab: This is interesting. Let's go into this one a bit deeper, because what I see with a lot of organizations, you mentioned pace of innovation being critical, I agree. Now, what drives pace of innovation, from my perspective, pace of decisions, in many cases. And you have now started to look at this or shared with us a bit about this more. Now, with "Can I take vacation?" let's say this is something simple. If it's a wrong decision, it doesn't really hurt the business, right? But the battery packs, that's a big strategic decision. How do they take these with the structures that you just laid out and with the limited rules that they have?
[00:26:26]
Joe: A really good rule of thumb that I did not hear in Tesla but fits how I saw everybody act, so I've quoted it since then, why would we ever ask a human to decide this and then be really honest about the answer? So if it has to do with physics, like stress, strain, torsion, electricity flow, heat flow, which is everything about a physical system, everything about a battery pack, and most things about software too, that is far better a decision for a machine to make, for a piece of software to make. Really, why would we ever ask a human to make this decision? There's very few decisions we would actually want to ask a human.
[00:27:12]
Now, there are some, and Elon has made many of those decisions. That's what the master plan really is, master plan 1, 2, and coming soon, 3. Is Tesla a candy company, or is Tesla a sustainable energy company? Elon decided it's not a candy company. It's a sustainable energy company. Okay. So those are decisions made by humans, and mostly by Elon. Everything under that, how do we be an effective energy company, those are questions mostly about physics and markets. Those are questions for machine learning algorithms. Those aren't questions for people.
[00:27:47]
The product is the factory that builds cars
Sohrab: So in addition to...I mean, Elon has been quoted multiple times where he says, "Our product is not..." and you mentioned this as well, I think, in your talk that you gave at Agile Munich, "The product is not the cars. The product is the factory that builds the cars." Now, it maybe goes even further. You mentioned these machine learning algorithms. Someone has to develop them. I assume they're developed within Tesla. So that also becomes part of the product that Tesla ultimately is, which is a highly effective company. And as part of that, they are really fast at decision-making and taking good decisions, because more and more of those decisions are automated, which means all the analysis that needs to be done can be done in seconds, if not milliseconds, and here, you have your answer, without a lot of debate about it. Is that correct?
[00:28:36]
Joe: That's exactly it. The digital backbone of the Musk companies is their competitive advantage for speed of decision-making, and I don't think most people appreciate this. Now, for the people in the audience here, if that resonates with you, this is a new concept to most companies. They need you, as a coach, to try to understand this, try to prototype it yourself in your own life, and bring it to them to help build it up. Most companies don't have a digital backbone for decision-making at all. It's like the analog of most companies still using paper mail, and then, suddenly, a company skips email altogether and goes direct to iMessage. That speed is just so shockingly different in that company. And this is new. Most companies don't have a digital backbone for decision-making at any level.
[00:29:25]
Sohrab: Yeah. No, this is interesting because...I mean, so far, before...this is the first time I'm hearing about this. That's why I'm so fascinated. Now, before, especially when I run leadership courses, I emphasize a lot on this topic of decision-making. One, it's about decentralizing decision making, because then you build up more pace, and still, you want to make sure that those are also good decisions. And the other is, even if you decentralize decisions, and you've been part of many scrum teams, sometimes it just takes them ages to come to a decision because they are in analysis paralysis. And then you can apply techniques, like disagree and commit, from Amazon, right? It's already great, but it's still human-driven decisions. Now, Tesla takes this to a whole new level. Have you seen any organization outside of the Musk companies, Tesla, SpaceX, etc. also apply this?
[00:30:17]
Joe: Not at all, and I haven't seen anyone produce a vended solution that they could bring to a company. I believe this is a complete Blue Ocean or very near, because I've not...it may exist. I've never seen it anywhere.
[00:30:31]
Sohrab: Yeah. I mean, that could be a nice product to build, huh?
[00:30:34]
Joe: I think it would be probably the product. I think it is the product.
[00:30:39]
What other elements would you consider being some of the characteristics of the best companies?
Sohrab: Yeah. It's the product. Now, we're already going from, like...okay, what I summarize, we can build hardware more or less in the same way, and there are many talks where you dive much deeper into this topic and your workshops as well, in the same way, based on the same principles that we apply to agile software development. And you've already gone into some of those things that are the differences between the best and the rest, the pace of innovation, part of that being, like, not human-driven but, like, machine learning-based decision-making. What other elements would you consider being some of the characteristics, some of the qualities, of the best companies, mainly Musk companies, but maybe a few others that you can also talk about, compared to all the other? And let's focus on the automotive space because you have seen a lot of those companies as well, both the OEMs and the companies that build the parts for them.
[00:31:37]
Joe: I'm really glad, Sohrab, that you have such effect and resonance and audience in Germany, because that's where some of the most interesting stuff in the world is made, physical, cool stuff is made. And all over the world, but Germany truly is a center for hard goods, smart, good, reliable, high-quality, high-precision, hard goods. So no one wants to hear they're the rest versus the best, but let's apply some kind of measure so that we can check ourselves. How quickly does new product get released? And when we decide to make a change, how long until that change is in production?
[00:32:19]
For most companies, they can cope with some level of supply chain variation within a day. "This type of bolt has run out. Let's use another type of bolt." That's already difficult, but that's largely the state of the art. "The overall design has been locked two and a half years to seven years ago." That's normal. That is the rest. And a certain level of fluctuation is tolerable, right, but the design that we're building towards is locked for two and a half to seven years, typically. The best, the design is never locked. There are changes to significant pieces of design daily. And what that means is the certification process, instead of being run every two and a half to seven years or even every three months, it's a daily certification process. We can't change anything unless we can certify it. So the certification process is made super-fast.
[00:33:17]
And this is exactly what we all saw in software. Some companies would run mass integrated tests every 18 months, and they're like, "What do you mean you want us to release every month? Our testing is every 18 months. We couldn't." And it's right, you can't. The pace of test has to equal the pace of product release. And we saw that in software. And that gave birth to what we all now know as DevOps, automated test and deploy as a package, right?
[00:33:43]
Well, the best are doing DevOps, whether they're doing consulting, whether they're making legal decisions, whether they're making financial decisions. Whatever their test process is, their audit process, they run it as fast as they make recommendations or make decisions. And it's absolutely the same in hardware. The audit process of "Is this hardware safe, legal, cost-effective, using an ethical supply chain," that audit never stops running. So you can release constantly. And absolutely, the best is new product is designed and built as fast as three hours. In some cases, as quick as 45 minutes. Much more often, around two days.
[00:34:28]
Software should never take more than two weeks, no matter how complicated we think it is for an actionable release. And for most companies, that hurts to hear, right? Software takes a year, more than once a year. Hardware takes three years, five years. If any project, hardware or software, is taking significantly more than two days from saying, "We should do it," to "We're using it in production," we're probably using waterfall. Like, we're probably using a 100-year-old method.
[00:34:58]
Sohrab: There's a lot of room for improvement. Yeah. So I was just speaking to a participant in one of my courses. I can't name their company, but they build medical devices, like, MedTech. For them, it takes nine years, right, from ideation to bringing something to the market. Now, one part of that is, like, everything that you mentioned. The other part is not the certification process that they do internally but the certification process that is done externally. Can you talk a bit about that, how that can be sped up? Because if I remember correctly, you have worked with organizations where they also had this external stakeholder who needed to certify things.
[00:35:44]
Joe: Yeah. So in COVID, suddenly, we saw some vaccines getting approved in months instead of years. So it seems like it's possible. What happened? How did it happen? What the world government regulator said is, "Well, anytime a COVID vaccine was submitted, it immediately went to the top of our queue, so there was less waiting." So that means it's mostly waiting time. Interesting. Okay. Well, what companies are doing, not just COVID vaccines, what other companies are doing with whatever their regulation processes are is they're submitting very small changes as frequently as they can to learn how to work with their approver. So they say, "We made a small change here." So it's, like, 10 pages in the application for approval instead of 4,000, you know. It's a very small change, it's a very small piece of paperwork.
[00:36:44]
So that also makes it go near to the top of the queue, because many organizations have a sorting algorithm that's not just first in, first out, it's also, "Let's try to get some of the short things done first." So that bubbles up. Then they get the questions back, "Okay. But we need you to show this type of field study. We need you to show this type of result. We need you to analyze this type of failure mode." Now, the company is learning, for what type of approval, what types of questions come back. And if you're a company like Tesla, you're feeding those into a machine learning database.
[00:37:18]
Sohrab: I was just going to go there, yeah?
[00:37:20]
Joe: Now, you've got your clean data of how your approver likes to operate, and you build your machine learning stack bit by bit by bit. And this takes years. But you start now, and you try to get the clearest data you can. And you submit as often as you can, if you can, once a day or more, without frustrating people. So that's why there's these short approvals. And the end result is you have an expert system, a very simple machine learning system that says, "For this type of approval request, here is the perfect submittal that already answers the questions that are likely to be asked." And that makes it even shorter, because, then, you can cut out everything that's not in that perfect submittal.
[00:38:04]
Often, you can get down to a one-page electronic page but the equivalent of a one-page submittal, and these can be approved almost instantly. It already answers the type of questions the approver wanted, you've built trust with them through all the small approvals you went through leading up to this, probably more than 100, maybe more than 10,000 truly. And now, you sent your one-page digital copy of a small change that already answers the questions they usually ask and has no extra unneeded information. Oftentimes, the approval is less than a day. I'm seeing this in more and more and more types of industries and in more and more global governments. This seems to be the method.
[00:38:44]
So ideally, we would pass some laws, and government would be a fast-responding test organization. Wouldn't that be great? But the method I just described has nothing to do with changing the certifying approver or certifying approval process. It's about responding very effectively to how they like to work now.
[00:39:04]
Improve the processes
Sohrab: Yeah. It actually emphasizes on what organizations can control themselves without feeling being a victim to the overall situation like, "Oh, we can't do anything because of the certification processes." No, you can, right? You can, A, ask them frequently, which builds trust, B, through having those small things, as you mentioned, you end up at the top of the queue probably more often than not, and C, you can learn what they require based on the questions you get back and then become better at submitting the stuff. And that, again, feeds the flywheel because they build more trust, and you can do smaller increments, and you succeed. I had never heard this before. I'd heard about it a lot, being a medical doctor myself, about the rolling reviews happening throughout COVID with regards to the vaccines, and that was fantastic.
[00:39:58]
Now, a lot of the companies that I work with, they say, "Yeah, yeah, yeah. But that was only because organizations or countries, not organizations, countries needed to get vaccines approved." And, yeah, they're right. Still, the approach was a bit different with the rolling reviews. But now, the strategy that you laid out adds on top of that, right, and this is super helpful. Now, when I...
[00:40:22]
Joe: As you said, it becomes automated. Like, it becomes 100% automated. There's no human submitting for review after a certain point. The machine learning algorithm is simply scheduling, sending these documents out multiple times a day. There's no human in the loop for approval anymore at all, at some point.
[00:40:39]
Sohrab: And hopefully, at some point, on the government or on the regulator side, there will also be a machine that looks at this and says, "Yep, works," and then it's even faster. Now, based on what you just mentioned, I wrote down another thing. So in addition to the pace of innovation, I think the pace of learning within the organization, be it humans learning story or machines learning, that's another one of those characteristics that distinguishes the best from the rest. And we're not saying that the rest is bad, they're just not part of the best. What else is out there? Pace of innovation, pace of learning, what else would you put in? I mean, there's a lot of things, but what else would you emphasize on?
[00:41:20]
Joe: You're one of the very first people, Sohrab, who's ever taken the conversation this way, and I think it's as important or more important. In one way, for our lives, we are the product. Musk says the factory is the product, and then we got to talk about, here, the decision-making system, the digital backbone is the product. Yeah, that's likely true. Well, in our own lives, we are the product, and I think Musk agrees with that too. I think a lot of people agree with that too. Bill Gates really stressed that, "How rapidly can we improve in our capability, our skill, and our knowledge base?" Bezos, too, in a different way.
[00:42:04]
And for that, I'd like to take it to mob development. I have never, myself, learned faster ever, and I've never seen people become more skillful, become high-skill, and more cross-functional faster than doing mob development or, more loosely, ensemble development or swarm. But I'm particularly blown away by formal mob development for hardware work, for legal compliance documents work, for software work, for all types of work, every type of work, including physical work, like building cars. Now, the hurdle we have to clear is, in mob, you have a group of people doing one piece of work, and the hurdle is, typically, why would we have a group of people doing one person's worth of work, in this mob, instead of, like we did before, having one person do multiple pieces of work at the same time? You know, context switching. Why wouldn't I load multiple tasks on one person, instead load a whole group with one task?
[00:43:12]
And for that, we actually have to run it and see results. Fujitsu, Zaibatsu, so both of those in Japan, Hunter in Silicon Valley, who else, many more have taken an hour of time and had people work alone and measure the speed, how much is done, whatever the type of work is. And then those same people later work in mob, formal mob, where one person works and the other people, like, cheer for them and build their confidence and answer questions. And they rotate who does that work. At first, in all cases, the measure was people working alone looked a little bit faster. Mob was actually nearly as quick but a little slower. Then, when they took into account the rate of defects found and the time it takes to fix the subsequent defects, all companies reported they had never seen faster output, quality output ever than mob. So that would clear that hurdle. So for people who guessed that, try it in your company. View the results from Zaibatsu, Fujitsu, Hunter, and then run it yourself and check.
[00:44:17]
Now, if you're brave enough to do it, the pace of learning is ridiculously fast. We could be doing something that no one in the group had ever done before, and someone's on YouTube, and someone's thinking hard, and someone's calling their friend that did it, and we're just trying. And the rate of learning is ridiculously fast. Even better if at least one person in the group has done it before or is an expert, then they can be giving some level of advice or instruction. And by rotating through the shared knowledge, even that experienced person is learning tremendously. People often say, "You learn better by teaching them, by doing," or "To ultimately learn, you need to teach." Well, mobs makes that concept very visible. In one hour, the amount of skill someone can have in an entirely new domain is inspiring. In 100 hours, the level of cross-functional growth is ridiculous.
[00:45:13]
The time I spent in Tesla as a full-time employee was actually very short. I posted it on my LinkedIn, it was very short. The amount of information I learned in that time because it was all mob or swarm or ensemble is ridiculous. My head is still full. I've never learned so much about building and programming robots, about paint coatings, like, the physics of paint coatings, what actually makes flow through a supply chain, how to cope with embedded electronics, charging electronics, and charging conduits. The breadth of skill is terrifying to a union, to a labor union, where they say, "No, your one job is to do this one kind of weld for the next 40 years, and then you're going to retire." So, of course, that person wants to protect it. They're like, "Well, no one else has to ever learn how to do this weld because that's my only skill. I've never been allowed to learn anything else."
[00:46:18]
So I'd say speed of learning for yourself, with some feedback loop as to that it's quality, quality learning, might be the only thing that matters for us, for our life maybe, if we are the product, if we are our life's product. And for that, I can't stress enough this agile practice of mob or, more loosely, ensemble.
[00:46:39]
How can cross-functonality help?
Sohrab: Yeah. No, I fully agree. So I talk about cross-functionality in almost every class that I teach, be it scrum master, product owner, or agile leader, because I want those leaders to really understand. I mean, if you want to get faster as an organization in terms of building new products, getting innovation out there, your limitation is the pace that your teams can work. And every team needs to be end-to-end so they have a low amount of dependencies to the outside world. And that makes it happen. Now, what I've seen is the same thing that you mentioned, right? They're like, "Oh, that's not efficient." But what is efficiency?
[00:47:16]
Efficiency is always looking at a certain time frame. If you have a short-term perspective, yeah, it's not efficient to have five people do the work of one person, but if you take that longer perspective, as you mentioned, right, taking in the quality issues that come with it, taking in, like, how much time it takes to fix those things, you just expand the time frame, you suddenly realize, like, "Oh, no, no, the previous way was inefficient. This is much more efficient." So efficiency is always depending on what the time frame is.
[00:47:47]
Now, from my own experience, there are professions where mob programming or mob work is very normal. When I was learning to become a surgeon, guess how you learn? There is one experienced surgeon. There are three others around them. They support. They support in increasing the quality. But it's mostly about learning. That's how knowledge is transferred. But in most organizations that I work, there is very little emphasis on teaching from more experienced people to less experienced people, and now, you mentioned that, within Tesla and Fujitsu and some other examples that you brought up, which I'm glad you brought up, because some people think, "Oh, that's only Tesla. We can't do it." No, Fujitsu can do it, right? Hunter can do it. Probably, you can do it.
[00:48:32]
Now, let's go from there. I think we covered a few things that are super interesting, pace of innovation, pace of learning as an organization, pace of, like, also learning as an individual. What are concrete things that you would recommend to an organization that says, "All right, I've heard Joe. This all makes sense. Now, what do we do next?"
[00:48:53]
Joe: Well, clearly, you take Sohrab's classes. Like, really, really. You make sure people have that fundamental understanding, and you go through all of them. You make sure they have that understanding of what we thought was a leadership level, what we thought was an engineering level, what we thought were the levels in between. You do that. You establish systemic-wide understanding of what is possible, and then you try to remove any impediment to everyone being a contributor. And I'll put a number on this, financial efficiency.
[00:49:26]
Most companies have about 40% to 60% of headcount not directly improving the product or service. They're in meetings about the product or service. They're making decisions about the product or service. They're not directly improving it. We call these different layers of...usually, leadership is what we call them. And for most companies, that's 40% to 60% of total headcount. Well, interestingly, that 40% to 60% often gets paid more than the rest of the company. So it ends up being approximately 80% of the company's human resources expense is on people not directly improving the product or service.
[00:50:08]
It would be more efficient if near 100% of the company's salary spend, headcount spend, HR spend, was on directly improving the product or service, for the company. That's what's called financial efficiency. The game then is, what can we do to make people still enjoy their work and behave as a legal company, make this a fun, easy to recruit, easy to retain top talent place to work where a higher and higher percentage of total HR expense is directly put in to improving the product or service?
[00:50:44]
Well, here's how the Musk companies do it. One, they automate most types of decisions. So that digital backbone of the company means a lot of different types of managers, leaders, coalitions. There's less of a need or, in some cases, not any need for it. So you can have engineers, those engineers for hardware, software, and often, they do some of both. As shocking as that is to sound, this cross-learning really works. So often, they do some of both. Those engineers, when they have a question, what they do is they create a machine learning stack to help give them the answer. That's their manager, right, and they write it themselves.
[00:51:25]
If any of you watched AI Day part two on September 30th, 2022, the teams designing the humanoid robot said that again, and again, and again, and again, "How many joints should this robot have? What's its movement vocabulary? What type of motor should we use? What type of torque should these motors have?" things that you would previously ask some project lead. Every time, they said, "We wrote the machine learning stack to answered the question this way," and they show it. They show the point cloud, they show the overlap cloud, and they show the software giving them the answer again, and again, and again, and again, and again.
[00:51:57]
So you have a higher ratio of learning. They now understand the actual physics that require that decision to be made effectively, and there's no waiting. These machine learning stacks run in seconds, and they can run them again, and again, and again. As new data comes in, they can always have an updated answer, and they never have to wait on a coalition. So that has reduced the need for leadership overhead, but then, how do you keep people motivated? In most companies, people want to climb this ladder. They want to get to the office where they can attend a lot of meetings, but they're nice meetings, they're catered well, they have a nicer bathroom, a nicer parking space.
[00:52:37]
Well, what Elon did is Elon made sure it's pretty nice for everybody. Everybody has really good coffee. There's awesome coffee, and everybody has it. You can have as much as you want. So, for example, everyone drinks the same coffee. There's not, like, the executive coffee room over in the executive arm. It's all the same coffee. It's all the same bathrooms. There's no executive chefs. There's no difference in parking. Everyone gets valet parking, and you get a really nice parking experience. You get a really nice coffee experience. So now, there's no reason to climb a ladder to get to the good coffee, to get to the meetings with better food. Like, that's gone. Everyone has the same experience.
[00:53:16]
Then, Elon makes sure everyone has access to a ton of money, if that's what they want. You get a really base-level salary in a Musk company. It's around $22 an hour, and just about everybody makes that. Well, how do you attract people from Google? I mean, Tesla and SpaceX are the number one, number two places to work for all engineers. How do they get that? And these include deeply experienced engineers that already have tenure in top companies. Well, there's two ways. One, you make sure they can get access to a lot of money, and what the Musk companies do is they make sure your stock options are amazing. Many of the people I worked with already had more than $1 million, and they can continue to work because they liked the work and they were passionate about the mission.
[00:54:06]
So you take money off the table. Everyone has, like, universal basic income, basically. And then you have great stock options, and they're invested immediately. Because the last thing you want is someone who's angry and doesn't want to be there, but they're staying another 90 days so they can get their stock. You don't want that. You don't want people who are angry and don't want to be there. So they're invested immediately. If they're really unhappy, they can go. There's nothing holding them. And that's important, actually, if you want the people who are there to be excited and mission-driven. And then that's the other part of it.
[00:54:37]
So now that money is off the table, the people who are there, the 110,000 people who are there, are excited about the mission and like the work. So you're in this really happy, high psychological safety environment, which people like, humans like. And your output as a person is, many people have said, and I think it's true, 10 to 20 times the output of most other companies. So your life output is so fast you feel you're accomplishing something that, especially if you believe in the mission, you believe you're accomplishing something towards a mission you agree with. Your feeling of satisfaction is through the roof because the speed is so fast. And it's fun, and the coffee is great, and the parking is valet and really nice. Like, you're having this really good experience, you have a ton of stock, you're working with all these motivated smart people, some of them the best in the world, and your personal output is through the roof. So, of course, you stay.
[00:55:37]
Well, now that you've got this system where you don't have to climb a ladder to retain talent and attract talent, and the reason, that business reason, was making these decisions, and you have even better decisions even faster, eventually, through the software stack, now very nearly 100% of HR spend, of total staff spend, is on directly improving the product or service. And that is financial efficiency, and at the root, that's what the Musk companies are doing. When you look at the value of these companies, how efficient they are, and how their growth rate, their expansion rate, how did they make the best car sold in Germany, the car most sold in Germany with the highest safety, when they were just a tiny company 10 years ago? How? How? How? When Daimler-Benz, now Mercedes-Benz, made the first car, you know, how did they out-Benz Benz? Well, that's how. The financial efficiency is near 100%, and in most other companies, it's closer to 20%. You just can't compete that way. I mean, it is business fundamentals underneath.
[00:56:44]
What are your key advices?
Sohrab: Now, that's really, really cool. I mean, it's one of those things that we would refer to as management innovation, not necessarily, like, prop but management innovation, right? They completely rethought how to do this. Now, given our time box, Joe, we are almost at the end. What is one of the final things that you would say? There are still some topics that I would cover, but we can maybe do this in another time. What is, like, some of the final words that you would bring to companies right here in Germany, especially in the automotive space? I know that you work with some of them, so you don't have to name them, but what would be your key advice, in a few sentences, on what to do in order to still be a player 5, 10, 15, 20 years from now?
[00:57:28]
Joe: You set a goal for the company that'll last for at least 1,000 years, so something meaningful, something that you think your company could really try to achieve over the next 100, over the next 1,000 or more years. You set that goal. Then, you set a KPI that's easily measurable that should contribute to that goal, and you automate that measurement so everyone can see it nearly instantly on their phone and on monitors in every workplace. So now, you've gamified the company with that one KPI. Then, you do your chores. You relaunch your company where people have a radical level of permission to self-organize, as long as it's around that KPI. And that KPI will change. That KPI is not going to last 1,000 years, but it's a meaningful step, right? You relaunch everyone. So basically, they take all of Sohrab's products, all of Sohrab's training, right, really, and relaunch them around that one KPI.
[00:58:28]
And then your next part of doing your chores is you find anyone who's refusing to contribute to that KPI, because they're not interested, it's not their job, they think it's not their...they're above it, and you try to grant them early retirement. You want your company full of people who are excited about the current mission towards your goal. And now that they've been relaunched with this agile DNA, through Sohrab's classes, I'm not kidding about that at all, then you protect those people who are excited from anyone else by giving them early retirement or sequestering them into company B, or whatever you have to do. Now, you have a company that can survive and should survive for 1,000 years. And if you don't do that, your company probably won't and probably shouldn't survive for 1,000 years.
[00:59:20]
Sohrab: Yeah. That's similar to...what's the guy from SoftBank in Japan? Masayoshi Son, right? He has this multi-generational perspective, 120-year, 200-year perspective, on his companies. Joe, thank you. That was really inspirational. We have to do it again.
[00:59:41]
Joe: It's my pleasure to hang out with you. I mean, we're friends anyway.
[00:59:44]
Sohrab: We have to do this again, my friend.
[00:59:48]
Joe: For people that have comments or questions, send them to Sohrab or you can send them to me. I'm @JoeJustice on Twitter. You can see my site. It's abi-agile.com. Agile Business Institute, ABI, abi-agile.com. I wrote a book. It's in eight languages now. It was just published in German. So for those who prefer to read in German, this is our book launch party or part of it. It just went to press two weeks ago. I mean, this is fresh for me, as of this recording, it's now. But it's also in French and English and Spanish, so the language of your preference. And chapter 21 is what I learned working for Elon Musk. So some people here might enjoy that.
[01:00:33]
Sohrab, it is my honor and privilege to rock with you. Let's absolutely do this again. Let's have an agile board meeting in Hawaii, board like surfboard or board like leadership board, in Hawaii. Let's do that in Q1. I'll invite some of the great people from Agilizer and Agile Human, and these other cool groups, to come, hang out. Let's have some pineapples and some Kona coffee. I'll find a way to make that open to anyone who can fly over there.
[01:00:56]
Sohrab: That sounds really good. Joe, thank you so much, been a pleasure. We will link everything that you just mentioned so that people can easily access it. And hope to see you soon. Bye, my friend.