Hello friends, this is the Alphalus Podcast. I am your host Toby. The goal of the Alphalus Podcast is to empower CTOs with the info and insight they need to make the best decisions for money. We do this by hosting top-fought leaders and picking their brains for insights into technical leadership and tech trends. If you believe in the power of accumulated knowledge to accelerate growth, make sure to subscribe to this podcast. Plus, if you're an experienced CTO, you will laugh the discussion happening in our Slack space where over 600 CTOs are sharing insights or visit one of our events. Just go to alphalus.com to apply. Welcome to the Alphalus Podcast. I am your host Toby and today with me is a former colleague of mine who already was on the podcast once and he is such a great guy that I just re-invited him today. It's Eric Bowman. Eric, welcome. Thank you Toby. Great to be back. It's an honor and a pleasure to return. Thanks for having me back. For me as well. And just as a quick reminder, so Eric and I met at Zalando where Eric was VP of engineering and beforehand he worked in gaming. So, Max is right. You worked on the Sims. Is that correct? Yeah. And after Zalando, you basically turned CTO at TomTom and now you're back to gaming and you're working as CTO of King.com. That is correct. Yes. Great. So first of all, so why gaming again? Why the hell? Yeah. Well, my career has been a series of loopbacks, essentially. I also worked in the past at TomTom and before I got into e-commerce and ended up at Zalando where we met and then I returned to TomTom and became the CTO of TomTom. And you know, I just like, there are certain problems that are just really interesting to me. And the combination of technology and fun is definitely one of them. And I mean, King is a really interesting business and a really interesting culture and it's kind of a tech company and kind of a game company and we're part of Microsoft now and all those things combined just made this really appealing to me. Okay. So then fingers crossed that you don't return to Zalando at CTO of Zalando at a certain point. Loopback always works for you. But yeah, like maybe quick, quick start. What problems are you solving right now? Well, you know, it's funny because what I did the. So I left my previous role without my next role lined up for the first time after 30 years of essentially last day Friday, first day Monday kind of job progression. I took some time off and considered my options and spoke to a number of different companies. And you know, what I found was that everyone I spoke to had more or less the same problems, which is, you know, how to actually do we organize people to consistently deliver value and enjoy the process. You know, I always come back to that we're incredibly lucky to do the kind of work that we do. You know, we're constantly solving problems and we're working in kind of an abstract and intellectual domain and it should be enjoyable. People should love doing it. But actually, there's a lot unhappiness in the tech industry in the early 2020s and you know, how do we organize engineering and product? How do we set goals? Is it outcomes or outputs or what is it? And I continually find that problem. It's incredibly interesting. There's a, you know, my last few roles, there's been a kind of a large C++ code base to reckon with. I also find that interesting, especially after years working kind of in Java and Scala, really getting back to the metal and how to make that work and how to how to apply many of the things that that we learned on the server side, essentially over the past 20 years and how to apply that thinking to make this so much harder domain of more heavy weight kind of client side code, go quickly. And you know, I mean, ultimately, like the semis was a magical experience that left you know, a little dent on the world and, um, okay, it has a mature, huge product, hundreds of millions of players and how do we continue to make that an engaging experience for all those people? It's just really interesting for me. So how to stay innovative, how to deliver in a way that actually makes sense, right? How to potentially optimize time to value, right? How to build, I don't know, an org that doesn't rely on micro management at least, like in a culture of, it's a lot of, we would have said agility, right? Or maybe let's let's centralize, right? Small a agile, right? Right? And how to deal with or how to stay focused in the domain you want to be focused on, right? Maybe we start with with output versus outcome because this has been a topic which I changed a lot. And the last, I would say like four years, right? That, um, many orgs became less driven by like just building for the sake of building, but building for the sake of producing meaningful outcome and output. So what's your perspective on balancing output versus outcome? Like, I mean, outcome is important, but measurable outputs have a value too, right? So what, like exactly? And does one always feed into the other or not? And how do you balance that in your day to day? And how do you actually make sure that modern delivery orgs are, like, first producing the meaningful output that then like feeds into into proper outcome? Yeah, that's really kind of top of mind these days, for a lot of folks. See, a lot of people talking about this on LinkedIn, for example, and, you know, there has been I think a useful shift, I think you use the words outcome over output. And, uh, that isn't, it's an important perspective, but I also consider it a harmful perspective, because it's not over its end. And, um, we have to have outputs that drive outcomes. And neither alone is sufficient. If we only specify outcomes and don't care sufficiently how we get there, we're unlikely to get there. You know, if there aren't no outputs, there aren't no outcomes. And, you know, the idea that the outputs don't really matter, I think, first of all, minimize is a little bit what is the most important role of engineering management, which is really accountability over output. And the way I look at it is that, you know, the main job of product management, at least the most universal job of product management is identifying what are the achievable or adjacent outcomes that create the most valuable, most value. And engineering management then becomes, well, how do we, what are the outputs that will, you know, most quickly achieve those outcomes? And how can we do that efficiently and in a sustainable way? This is actually kind of a helpful breakdown, in my view, in terms of like what are engineering managers and product managers actually accountable in the real world. One is describing, you know, discovering and describing the outcomes. And the other is then being accountable for the outputs. And that kind of forces the cooperation, but it holds both outputs and outcomes kind of at the same level. There are parts of a value stream, like a universal value stream. Actually, like just over a year ago, there was this incredible McKinsey piece that made a bunch of noise about how to measure productivity and many very smart people contributed to, I think, a global conversation about that. And Kent back talked about this kind of value stream. I think he calls it efforts to outputs to outcome, to impact. And I kind of like activity better than effort, but they're, I mean, very nearly the same thing. And I think it's a really useful model because it really is a value stream. It all has to connect. And each part has to be kind of separately and independently manned.
in some ways. Sometimes it is self-management, but we each part needs to get sufficient attention and energy. We need to be improving every part of that value stream all the time. And where do you typically start? I mean, if you now started a new job, like, how do you check if the right measures are in place? How do you check if the organization is actually moving in the right direction? I think like, I mean, a meaningful indicator is often revenue, right? Yes. Money flows in. That's kind of outcome, right? Yes. How do you call that impact? Or impact, yeah. How do you move from that impact or meaningful outcome? And how do you then move to output? Or do you start an output? Like, check, I don't know, how many git commits were, did we see in the last three months and how did that? Like, I don't know, compare to the two months before or something like that, right? Do you do that? Or would you do that? Or how do you, how do you actually look at, look at output first? I think it's a bit situational, but I'm given kind of my background and my interest. I always kind of start to try to understand what's the relationship between engineering management and product management. That's almost always where the friction is. And, you know, they're kind of different, like, you end up with different, well, on the one hand, so there's this kind of spectrum where you have sort of like the Marty Kagan approach, the Google approach, which is a counterparting of engineering management and product management. At the other end of the spectrum, you have the kind of the idealized Amazon single threaded leader with kind of holistic leadership and commercial product and engineering accountability with one person. And I've now worked kind of in both extremes of that. And I wouldn't say, I necessarily have a preference, but there are trade-offs between the two approaches. But ultimately, I think the most important thing, or at least I think where I would recommend starting, although I do think it's highly situational, is to understand the output to outcome. How is that bridge made? And then, you know, the kind of activity to output, how do people work, you know, how is work planned? Do the build systems work? All that. It's sort of separable. And that, you can look at that relatively independently. And then at the other end of the spectrum, so I've found it helpful to think about impact as kind of the sum of outcomes. So if you think about outcomes as behavioral outcomes, we do a thing to make a user or a player or whatever more likely to take some behavioral action, which will, you know, probably contribute directly or indirectly to revenue, that's kind of very much the focused domain of a lot of product management work. But though the sum of those behavior changes from users, players, customers, whatever they are, that generates the impact. And that again is also kind of a, it's a more separable, more into the product commercial domain. Do we understand what we need the people who use our products to do? But the friction point really is very often. Like, how do the engineers and the designers know what the problem we're trying to solve is? And then ultimately, how do we essentially create the kind of flow that's needed because we're never going to get it right the first time or probably even the second time. And so we have to be able to iterate quickly and the learnings from those outcomes need to make it back to drive activity. So there really is, you know, I mean, in a way, everything comes back to some form of flywheel or feedback loop. And those feedback loops, I think, are ultimately the most interesting thing to be thinking about, but I would tend to start, really sense, the output outcomes gap, if you will. So is there a close feedback loop, right? Like does feedback, like, yes, flowback to developers, do developers then pick it up, work on the things they are supposed to work on all they find like the, the right problems to work on and then does this flow back into the product. And from your perspective, you just compare the different product management ideas. Is there a silver bullet or is there like, is it a mix or is it organization specific? Like what is what is your view on that? I don't think there is a silver bullet. I think it's good for technology and product leaders to understand that spectrum. I think the spectrum is pretty universal. Like I can't imagine that you would overcomplicate it with more than two roles in that, at least in that core kind of what I call the universal value stream. I think that, you know, it's very challenging to get those single threaded leaders. I think Amazon's approach is we have to build them ourselves. And that was a massive undertaking and we have all of the kind of leadership principles and, you know, the system that they build is remarkable, whether it's going to scale into millions of plays, I guess we'll see. We might be seeing some cracks now. But you know, it's like this will probably come up, you know, if it's not really an adjacent possible for you, like if you can't get those people or whatever, then obviously having dual roles is a lot easier in certain ways. You can't actually more easily find people who are, you know, experienced at either engineering management or product management. And there are benefits to the approach when it's working while it is. When EMS and PMs, for example, agree on something, it's much easier as the executive level to go with that decision. It has, they bring some kind of pure review to the process compared to when a single person comes and says, and some helpful friction, right? Some helpful friction in cases. And I also question the single threaded leader approach. I mean, I know that it does exist. But it's like I see it often in founders, right? Like when I don't know, you see those, those YC backed startups where you only have engineering folks leading a company. But I don't see it a lot in the real world, especially because the jobs, let's say, an engineering manager or CTO and a product person, they have a different focus, right? Like the CTO typically focuses on keeping the lights on and keeping the system alive and keeping a healthy, like keeping the delivery stream flowing while the product person cares about tomorrow. And what do we do tomorrow? And this often conflicts, right? I mean, very simple. I would take issue. I'm not sure that should be the main. I mean, obviously it's an important focus. But I think CTOs need to be super forward looking. But I mean, there is a difference for sure. But I think one of the things has changed about how CTO roles look in this decade compared to the last is you're much more focused on the economics of what we're doing. Are we creating value? Are you know, what is the marginal increase in value creation per added employee, for example? And what can we do to reduce carrying costs? What can we do to bring value sooner? How, you know, factoring and cost of delay? Keeping the lights on is easier than it used to be. Yeah, you're right. It's of course super important, you know, existential if you don't do it. But if you are if that's the main focus is a CTO, you have a boring job. You have a boring job. I mean, it obviously also depends on the business, right? And some companies it's more complex to keep the lights on and other businesses less complex. And you actually have more time to care about tomorrow. But I see that pattern often that you have a natural tendency and you swing more towards like having stability as a CTO and being, let's say, a bit defensive when it comes to new things, while as a product person, you often have the job to deal with new things, right? But I agree that it's like maybe a bit simplified. Yeah, I mean, for whatever is worth, I'm not conservative. I'm looking for how can we move faster? How can we take, how can we, you know, moderate risk? How can we make smart risk decisions? How can we manage risk? But, you know, it's a tough world out there. There's no, there's no stable anymore. That's right. And in this modern world, did your view on how effective, let's not call them engineering teams, let's call them product teams, or diverse teams, right? I think there has been a trend to diversify really
on team level and to really have teams that consist of, like, say, engineering people and product people at the same time. And a bit of a trend towards smaller teams, do you agree that this is a good trend or does this solve issues that were harder to solve before? - So, I think I would say at this point, objectively, I wouldn't call it a universally good trend. Mostly, as we're into the zero interest rate, as we leave the zero interest rate period behind us, many tech leaders, myself included, it's kind of unaware of the impact of the macroeconomic climate. I grew too many teams and too many small teams and really focused on, we're just gonna grow. We're gonna build these different components of a bigger product and all of them, we're just gonna continue to evolve. I think the economic or thermodynamic reality is that that is not sustainable for the vast majority of businesses. I do kind of look at it with some interest, although no direct experience at kind of like bigger team approaches where we have like 50 people working together and they don't break up into smaller teams. So much, but it's more dynamic. I don't know if that works, but I recognize what it's responding to, I think. And we have tended to over-complicate and over-compartmentalize how we build systems against a sort of theoretical view of product decomposition and there's a coherence with cloud infrastructure, for example, and it really taps into the kind of need for autonomy. My conclusion after more than a decade is that it works to a degree, but it also is a form of organizational debt that has to be paid back at some point. Many companies are currently paying that back. And so I actually, I've committed sends in this area. And so I gave master class on autonomous teams and my own thinking is constantly evolving around this and King is quite famous, I think, and some circles for the degree of autonomy and it's part of the culture and part of the values really of the company. And so keeping that going is top of mind for me. But I think, if we go back to flywheels for a second, one of the hardest things for tech people in my experience or maybe it was just me, but I don't hear people talking about this so much is this idea that in any kind of commercial enterprise, any kind of enterprise with nonprofits as well, you're trying to do a thing that causes a thing. And so in the kind of universal value stream, it's like we do the activity that causes the output, that causes the outcome, that causes the impact, which is a pretty long causal change actually. And it is kind of beyond most people's intellectual ability to really be able to understand how even that long of a causal chain really works, which is probably why it's actually really hard to make a good product. When you think about a flywheel, we're actually creating a causal chain that closes in on itself, which is almost unimaginably difficult again. But somehow, you know, what kind of emerges for me is one of the most important concepts for how to organize its scale is really to do the work to understand more about the causal chain that is relevant to individual teams and how what they are doing is genuinely contributing to the higher order goals. And then, you know, sort of back to the feedback loop concept, creating the conditions where there's an expectation and kind of the environment to really learn, do we actually understand enough, you know, I mean, it's a complex system and their external factors, you know, causality is a pretty high standard. But still, we do things and at least correlate strongly with what we hope will happen some of the time. And so what's kind of merging for me is that the most powerful driver, however you organize, is that people working in teams can are working toward goals that are, that may be like kind of commitment goals, but it's clear how they contribute to something bigger than just what the team is doing. And that there is this dynamic that is like, we're trying to learn kind of quarter by quarter or a month by month or whatever, spread by spread, whatever the right cadence is, we're trying to learn more about how what the things we do actually, what the causes that they create. And that's very often in the form of behavioral outcomes for many, many products, especially online products, but not exclusively, but ultimately it has to, you know, contribute to creating a business that can either, you know, do more with the same or the same for less or maybe more for less. But all those things have to come together. And when I see a team that cannot, that is not making that connection, it's almost always an underperforming team or like untapped potential team. And the correlation between seeing a team that is super engaged, moving fast and having real impact, they have, Mike's being always like clear goals that they're working toward this learning culture and they understand that they're trying to improve whether it's just in a product management sense or a combined product engineering, the mental model for how the system works and how what they do can actually improve it for users. And so I was a little bit slow, honestly, on the goal trains. But, and mostly because I wasn't able to see past the immediate sort of period, like the power of goals is not the immediate period. It's the cycle, the repeating and the learning that happens when like, if we knew then, what we know now, what we have done differently. - And if you talk about the goal train, do you follow still things like OKRs or do you just simplify these days? Because I get to find it like those systems to complex to basically keep up the discipline to really follow them. Do you think like people also spend too much time on like following systems because they think that big organizations invented those systems and that's why they have to work. And as soon as it has a name or follow some idea by Google, it actually must work. Like how do you see that? - So that definitely happens unfortunately way too much. That's also one of the big problems with scrums. It becomes a, what Richard Feynman called a cargo cult, where if we just go through the motions, the planes will start landing on the runway. I mean, OKRs are problematic. Just like everything is problematic. But if people genuinely commit and they're meaningful and they get reviewed, they actually work pretty well. It's the commitment part. And also, I saw something recently that really kind of stuck with me. The simplicity of it was appealing because I'm not the most disciplined person in certain parts of my life. Pretty disciplined in others, but I don't think any would objectively hold me up as like some kind of like torch bearer for discipline necessarily. And so it's like, does discipline come from motivation or does motivation come from? Discipline. - It's actually, I think I can't remember exactly how it's put, but it's basically action creates motivation. And then once the motivation is happening, then discipline is sort of like an output of that. That at least for me, like discipline on its own, even though intellectually it is a p-ling and where I applied, it's useful. It's hard to maintain. So when you look at organizations to talk about the bias for action, when they actually live those, that's where a lot of motivation discipline comes through, especially over time. And so the kind of the connection between commitment and action, and it's like we are committing to OKRs or whatever. And when that is kind of at scale, whatever it is, it's way better than without it. - Then nothing. Bye.
Yeah, you know, so what but so one of the problems with OCRs is that they are unordered and I I don't know if you were still at Zalanda, but we did the same global Global initiatives or global programs where we had a Ordered list of like the top N where N was kind of less than 10 Programs that required multiple teams to participate and I'm pretty effective like it was I mean nothing is perfect But compared to what was there before we were able to move bigger things and I took that into my kind of standard toolkit and Implemented something similar in my next role and I'm kind of looking at it now But I really tried to understand like what is it? That makes that work exactly I mean there are like the way it was explained to me originally You know was that with these complex programs you have a bunch of teams and and very often you know Seven of 10 teams do the work and then we dropped the ball the last few teams we lose focus or discipline or motivation or whatever it is And then you've you know, you've got all this sunk cost and that's a problem and it's kind of like actually kind of common In large organizations that these things happen. So that's an obvious benefit But I was really trying to understand more fundamentally What is the effect of having that kind of stack ranked prioritization and also you know, it's like well actually ordering it is super hard and Executives well like don't really least what I know and me Don't necessarily want to do the ordering because you know if you're wrong Maybe the system can self-organize into a better ordering And then I had the following insight which is that Very often there's there's a few teams That have to contribute to multiple things like you know if there's some kind of user data platform or you know Like there's just always a couple teams that just everything depends on And those teams become high contention points if you're trying to do multiple things at once And it's a very you know, hairy problem to figure out how to actually Organize work to be efficient But what that stack ranking does is it basically forces all of those teams to do work on these initiatives in the same order and So it's a natural kind of whip limiter for those bottleneck teams And that improves the flow for those teams And then assuming the teams that depend on them are also following the stack ranking and saying like if you can work on this one You know do so before you work on that one The overall system effect of this thing is it actually increases flow in a way That is very kind of Kanban ask but without having to manage Individual whip in an individual team it like is an emergence whip-producing System behavior We're producing system behavior. I what what I sometimes also find effective is basically The idea of having one goal, right? Like especially for those teams like for quarter you just oh for sure have one very simple goal because like what I found always Like happening with also goal systems and okay ours. They are often decoupled from the actual Delivery right or from the actual day to day of the organization and then yes, you basically meet back at the end of the quarter And then I don't know people try to I know close them down in a minute which obviously doesn't work right But but I think that's also like signs of it like an unhealthy introduction of goals or okay ours, right? Yeah, there's maybe the missing commitment Yeah, I think the other thing is that a certain scale like you're always working on the next quarter or whatever time intervals goals It's like painting the golden gate bridge. Yeah, if you save it until the last two weeks of the quarter You know, you're not gonna do I'm not gonna do anything right like I mean, I mean you maybe I don't know if your goal is to close down bank accounts You rationally close down bank accounts at the end of the quarter or something like that right which causes lots of harm So and that Just mentioning that because that that happened back at Solando To me actually like can we close down your bank account Like one day but Yeah, I Think Back to this singular goal this actually often source There's this traffic problem that you just mentioned in and very Like under fire teams to really like still achieve something which is Forward looking while still working on all the maintenance and helping others and whatever Where it's lots of context switching right because if you just have one goal you can always do drive back to that right You can always move back to that and deliver That is also a natural whip limiter But I'm not always possible to only have one goal, but but I would say the smallest number of goals you can get away with Absolutely, but I would also say and actually wrote some code to simulate this because I was so You know, it's like oh this actually there's something to this it to a large extent it doesn't even matter What the stack ranking is as long as everyone agrees with it you will get benefits If the system is at all kind of like normal Absolutely So I still want to want to shift gears a little a few days ago. I don't know if you saw that but there was the release of the new Dora report yes, and As far as I see it like people start questioning Platform engineering while I mean first DevOps broke and now I see like platform engineering being being questioned and and The real value of platforms is Is at risk, let's say Yeah, how do you see that? I mean you also I'm just like we didn't talk about it before but you were working at many orcs where I Don't know at a certain point people started introducing platforms and building platforms and there were many people involved like Maybe building something which like no one really needed That's how I also see it in some cases and I'm actually right now thinking about it like what what is what is the like tiniest level of of like introducing a platform And and and I see it like it is a very hard challenge like how do you see that like What are you doing at at King what did you do before what is your view on it? Well, what do you so I I did catch some of the Dora fallout voters more about AI assisted coding considered harmful Which is also pretty interesting I could see that but I also have some questions But what like platform is an overloaded word So I'm not sure which kind of platform are you talking about? Well, I mean in many orcs you have platform teas that then introduce Things that are supposed to make people more productive meaning measuring experience effectiveness productivity Starting to introduce tools like backstage Starting to really build something that like is supposed to make people deploy faster Like stuff like that right like we did we had many of many of those things that's a london I don't know what you have and your or how you see it And I think I think that often It actually leads to people being slower in their day-to-day Because they are not doing it the way they are used to or not the way it has been shaped by big vendors That you're potentially using but you I don't know you have your certain way to deploy in York Yeah, so I mean King is a special case and I might not get to into that so I'm not sure That's super helpful, but I think Yeah, things so one way to look at it is that is you always want to be on the lookout for what I would call compensating measures So for example if a like the HR team is Doing a bunch of the work that managers should be doing Because maybe the managers don't know how to manage Which is pretty common in in tech It feels kind of good to people you know, it's like well these people can't do it It's hard to change has to be done will step in will do this it gives kind of could give meaning say to some of the some HR work or different kind of meaning But it's actually weakening the system over time because
is actually those managers need to do that work. And I do think that we have overplatformed a bit and we tend to underestimate the long-term cost and difficulty of changing these things. So like trying to think hard about what will be needed is almost certainly wrong. Like you wanna stick to the adjacent possible as we discussed as much as you can. And similar to how language shapes how we see the world, what our platforms can do, also shapes how we see the world. And they end up doing things for us that maybe we should be doing and ultimately kind of making us weaker. So, I mean, I would say it's a risk, but I don't think there is, I'd hard for me to say platforms universally good, platforms universally bad. What I like about the direction that CTO work is going and what I mentioned earlier, which is like we're actually starting to really look at the economics of what we're doing. And at the end of the day those economics are about, what is the carrying costs of the work that we're doing, what is the cost of delay and how do we balance that against risk and then how does that connect to revenue. And I mean, what I am doing now actively with Teams is really saying, hey, we gotta map out these value streams. We gotta understand what value is flowing through them, which are the most important ones. We need to actually work to reduce the time to value and let us actually calculate because at least in my current role, we know very much over time, what the value of almost every single thing that we do is and try to map that back to like, okay, this is, we reduced the cost of delay this much. We brought in revenue this much sooner and then how we do that, it's like it's no longer good enough that it's like, oh, this is this great platform. It's gotta be a platform that we can evolve and that is essentially either contributing, I mean, at the end of the day, so another way to look at it is these are tech investments and there's only two reasons to make tech investments. One of them is the promise of future revenue and one of them is to accelerate future delivery. So which is it? And if it isn't one of those, we're not doing it. Basically. I think that's even cutting costs is helpful too, but focus on value creation. Yeah, well, either like basically lower the bottom line or like raise the top line, right? That's it. Yeah. It's how life is in a nutshell. But it's, it's not good. But it's also often easier said than done. You now mentioned the theory of the Jason possible for a few times. Yes. It suggests, as far as I understood it, it suggests that innovation in a company is essentially shaped by the tools and resources at hand. How do you see this in action? Yeah, so we talked about it in the warm up a bit. And it's something that is on my mind from time to time and I would encourage you, Jerry, the SNRF to go Google or chat GPT about the theory of a Jason possible because it is a really interesting way to the world. And the basic idea is that, you know, I mean, there are different ways that people describe it one way to think about it. But the basic idea is like, look, we're there's a set of possible next steps that we can take. And beyond that is very, very hard to see. And I mean, sometimes in a simpler world, of course, we can make long term plans and head toward that long term plan and all is great. But as things get more and more connected and technology does more and more and the world is bigger, you know, as part and part because of that connection, each step that we take, there's so much new to learn that we wanna at least make sure that we are learning at each step and that we are being small a agile to make sure to apply those learnings. And so it's this kind of, I mean, ultimately it is a simple mathematical model around innovation and comes from the sky Stewart Kaufman, who's very interesting theoretical biologist. And one way to look at it is, one way people describe it as like, suppose innovation, which is a word I hate, by the way, but we'll get back there a second. As a process of like pulling balls out of a bucket and you know, each ball you pull out is kind of a discovery or an invention. So the one that I remember is like you pull out the dance ball. It's like, oh, we've invented dancing and then the question is, well, what do you do with the ball? You don't put it back in because it's already discovered. But what happens is like, you know, a billion more balls get poured into the bucket. And so each step that you take can quite dramatically kind of cause you to kind of reconsider your biogen priors every step of the way. And so really interesting kind of way to look at the world and it has relevance for, you know, it helps explain why a lot of the best thinking in my view about what makes projects succeed, how evolutionary software architecture works and how, you know, good news over planning is not always appropriate. But it also underscores how important tools are. And so one of the successful ways that this has been applied is to look at a couple different scenarios. One is the Cambrian population explosion and another is kind of the 20th century kind of, you know, and from the industrial age into the post industrial age, how GDP just skyrocketed. And in both cases, you know, there's this, in the Cambrian explosion, there were certain proteins which came into existence, which could be combined in super interesting ways. And this genetic diversity exploded. And, you know, like if you look at how many tools humans had, say, 2000 years ago, it was something like 10,000. And if you look at how many tools people had sort of at the end of World War II, it was tens of millions. And so this, like the availability of tools, somehow just unlocks this opportunity to innovate in very surprising and effective ways. And so I think most of the listeners know thinking about AI and when, I don't know, the GPC. (laughing) - Exactly. - Yeah. - Yeah, so, you know, I mean, we, like basically with chat, we chat GPC coming out in like November 2022, it's like the adjacent possibility space exploded in a way that it maybe never has before. I mean, it's just, it's, and it's sort of disorienting and confusing for people. And everybody's scrambling to figure out what's our AI strategy. And then, you know, on the tools questions, like, are these chat tools, are they tools? Or are they tools for creating tools? I'm leaning more towards it's more tools for creating tools. And the tools haven't really emerged yet. And that actually could take a decade or two for really, for the right tools that actually lead to some kind of, you know, science fiction compatible version of the world. To really start to take off, we have a lot to learn. We have a new capability, but we just don't have the ways yet to figure out how to use it for anything other than very simple use cases. - Yeah. - Absolutely. - Yeah, I mean, obviously like most listeners, as me think of Alexa not being able to do anything. (laughing) And, and, and, and, where Alexa. (laughing) - No, I mean, please turn off the lights, please. (laughing) Could you keep trying until you connect with the device that's out there controlling the lights? Just keep trying. - Yeah, yeah, yeah. - And no, let's be patient with that, right? Let's be patient with, with Amazon adopting it. Let's, let's be patient with, with the word adopting it. And I think that's also what you sometimes have to do, right? I mean, things are like, or especially GPT in the year, 22 wasn't, wasn't done, right? It's, it's just like, the ignition basically, and not like the, the, the, the, the full introduction of, of, of an innovation to the world, right? But rather like something that you set, set into the wild to make people, and see people adopting it, and, and then, at a certain point, something that, that makes people actually more productive, but that, that takes ages, right? - Yeah, no, absolutely. And it, you know, it is fooling us. It's capable of fooling us in very convincing ways, that it is a sentient thing, and it's just, and it may become one, but it absolutely is not. It lacks, you know, common sense. It's a well-read, but not actually aware. But if it's able to play in our emotions, and our perceptions, and ingenious ways, and it's incredible, useful, they'll give me a ride. You, you use it all the time, but it's not,
not use is not scalable yet. And I can't really imagine yet actually automating something meaningful where you really could just let it go. Like the automation of it is way more complicated than just the doing of it. Now it's at the time. - Yeah, yeah, yeah. And that's what we have to understand, right? Also as tech leaders in the next years, like how do you actually, I don't know, build agents? That's like the new trend, right? The genetic AI, it's fun and how to apply it to really solve business problems. But let's see, let's see, let's be patient. So for us to believe Twitter, all that stuff works. (laughing) I haven't seen it yet. So what's then your final take on innovation? Like if you could describe innovation in three sentences, what would it be? - I think I only need to define problem, solve problem. (laughing) I actually hate the word because it's so weaponized. And it's like, you know, I mean, the joke I keep making is like if you want to see real innovation, let's watch how Amazon employees get out of five days return to office. The problem has been defined and they will come up, I'm sure, with very clever solutions. What people mean when they talk about innovation is like, how do we get our people? Solving the right problems and not solving the platform sucks or the tech debt is too high or whatever. And again, that really comes down to kind of building these causal chains of understanding what we're trying to accomplish. Then that becomes the problem to solve. And the idea of having innovation teams or the innovation is only for hack weeks. Nah. It's an everyday thing. That's what makes the job. Corporate incubator, right? (laughing) How helpful. So let's slowly have to come to the end and I prepared a little like quick fire round for you. So just three questions, name a tool or piece of tech you can't live without and one, you think is solely overrated. - Can't live without, I mean, right now it is actually unfortunately chat GPT. I could not, I don't wanna go back to the before time. - Yep. - Rather cliche answer, but they're definitely before and after. And overrated, I mean, at the moment, it feels like every single app that I use, unless it is truly great, it is terrible. Like I can't remember the last time I used an airline app that wasn't literally terrible, but I don't know if that means the bar of overrated. Ha, that's a good one actually. I think return-to-office is overrated. (laughing) - Okay, that's a good one. If you were an attack, what completely different career could you see yourself pursuing? - So yeah, my doc answer to that these days, I think ever since I read the book The Goal, is actually I think operations would be super interesting. Academia would be interesting. Actuarial work, I wish I were smart enough to do that. But yeah, I wish I had more time to write as well. - Okay, cool. Is there something tech-related or not that you're currently obsessed about and that you basically recommend to everyone, apart from chat GPT? - Time shifter for managing Jetlag as an app. - Ah, yeah, I see, I saw that app, yeah. - And related to that, there's something called loomost.tech, which is actually it's an iMask and there's a super fast flashing set of lights in it and it reprograms your circadian rhythm while you're sleeping. I think it might even be better than time shifter, but either one, at large the technology for managing Jetlag for people unfortunate enough to have to travel across time zones is a total game changer. Like, no reservations, stronger recommend. And if you had to leave my listeners with one key insight or innovation or ability, what would it be? - Build that learning loop, make time pay off and there's two things, time to value is everything. - Cool, thanks a lot Eric. Was a great pleasure to talk to you again. - Like, really, really insightful. You're a true wise guy. And yeah, let's have another chat in a year or so. See you soon. - Thanks a lot, bye bye. - Jump. - You would like to hear more about or a technical leader whose brain you would like us to pick. AlphaList is all about helping CTOs getting access to the insights they need to make the best decisions for their company. Please send us suggestions to
[email protected], send me a message on LinkedIn or Twitter. After all, the more knowledge we bring to CTOs, the more growth we see in tech. Or as we say on AlphaList, accumulated knowledge to accelerate growth. See you in the next episode. [MUSIC]
PodcastTranscript AI