Kai Hansen

[00:00:00] Good evening everybody. Good afternoon. I apologize about my non-existent French in the beginning and then we're we're having we're done, I hope. Um, I would love to do it in French, but really I studied Russian in school, which seemed like a great idea. In the late 80s, currently I look back at that maybe not such a great idea, but it's like, well, you never know. Any who, um, my name is Kai and um my topic today is myths and legends about Big Tech. Um, I'm roughly going to divide this into two pieces. So, we're going to do a piece on the myths and the legends, and then we're going to do a second piece that is a bit less missy and legendary, um, and more about like, what does it mean, right? Like, how can you here in the room, but everybody else as well. uh, learn from the things that some of these companies have figured out over time, have introduced into the world, etcetera, etcetera. Um, very, very briefly, I promise, uh that's the only thing I say. So my name is Kai, uh I'm an expert partner at Tiga. Um, very quickly. Does anybody know Tiga? Yes. A few people know Tiga. Excellent. I am in Paris. It's like, I if I do this uh talk in Munich, everybody's like, what what are we talking about? So, it's nice that there are some people here. Um, and uh yeah. I work with uh product teams, I work with uh product leaders, and I work with executives to try and build better product organization and build better products. Um, I've been doing this for about 20 years. And the first 13 were spent uh at Google. Um, I have a lot of friends still at Google, I have a lot of friends who work at other companies from that Silicon Valley, Seattle/ ecosystem. Um and so we're going to explore a little bit on this. Um, and um because it's afternoon-ish and I am the only thing between you and beer and a sunshine. Um, I am going to try and keep it active, right? So, I'm not going to talk all the time. I expect you to participate a little bit. Um, I was thinking my seven-year-old has a thing when school, when they all get snoozy after lunch, they do a shake break. So they all stand up and do some gymnastics. I considered that for a moment, but I'll spare you the shake break. But only in the condition that you participate and are are are active, right? If if I see people nodding off and dozing away, it's like I'm going to introduce a shake break at some point.
[00:02:54] All right, um, in case you actually want to afterwards, um, extend on this topic. Um, who has seen this?
[00:03:03] Oh, that's not as many hands as I thought there would be. It's like, this is an excellent take. Of course, it's a comedic take and it's exaggerated and it's over the top, and it mainly focuses on startups, um, and sort of the VC ecosystem. Um, but if you're okay with that, I can highly recommend this as sort of a comedic take on the Silicon Valley Big Tech culture. There is a lot of really well-researched nuggets in there. Um, I think it's three seasons, it's good fun. Um, feel free to take a look at it.
[00:03:40] Oh, sorry, it's actually the show is actually called Silicon Valley. It's a it's a US show from HBO. Um, sorry, I should have I should have mentioned that one. For for me, those five people are just six, six people are just so uh common that. All right, and I have one disclaimer uh before we start. There is actually not one Big Tech. So the title is a little bit of a misconception, um, but it's it's it's a misconception by design, right? Because a lot of people, like when they learn, it's like, oh, you spend a lot of time at Google, how does Big Tech work? I'm like, well, you know, there are some things that are quite similar across all these people and like I know people from all these other companies. But in reality, it's like Big Tech is not Big Tech. And this is one of my favorite comics. I'm not sure if you guys have seen it before, if not, it's really funny. I think people make other versions of this as well, so if you Google it, you'll find them. Um, but this is essentially uh a a comic take on on the structures of of the big technology companies. And and you can see that from an organizational perspective, they are completely different, right? My favorite is the Oracle one, although I also like the Microsoft one. Um, so so these companies do not operate in the same way. They don't have the same culture, they were not founded in the same era. They they are actually quite different. And so, what we're going to look at a little bit is sort of a Google biased one, because that's the part I know best, but we're going to try and focus on the things that unite them and that are sort of common across them, right? But one thing on this is actually because I always find it interesting. So if if you look at Apple specific Apple, Microsoft, and Google, they actually have three completely different DNAs, different cultures. Apple is a product company. Steve Jobs was a marketing person, right? So he thought product first, marketing second, and yeah, somebody needs to do it afterwards, but we'll figure that part out, right? First I figure out what people want and then we we do everything else. And it changed over time, but in its heart, Apple today is still a product company. Endless polish, super, super well-designed things. And then everything else. Microsoft is a business company. Well, Steve well, well, well, Gates was a great engineer, he is first and foremost a businessman. Not particularly popular for that, and you can argue that some of the things that he did were semi-questionable, but that's the way Microsoft came about. It's like, it's definitely been a business company, and I think Satia now has changed it a little bit, is sort of going back a little bit into something else, but Microsoft first and foremost is a business company. Google is an engineering company. Founded by engineers, led by engineers, owned by engineers. Um, if you work at Google, especially 10 years ago. It's like engineering ran the show, right? Everybody else was just there to help out with the things that the engineers didn't want to do. So the product was somewhat accepted as in like, yeah, at least you sort of know a little bit about technology, we kind of let you in the room, and then everybody else, yeah, we just don't want to do that stuff, but we know it's necessary, so you can you can be part of this, right? And so completely different ways of organizing the companies, of of of DNA and culture, but there are some things that are that are very similar. And so that's my hope that we're going to get through this uh by the end. All right. I threatened audience participation, um, and the brief on the website says bring your questions. Is there anybody that wants to ask a question about myth, a legend, what you have heard, is it really true, has it happened, is that the way it really went down? Other way I brought some, but.
[00:07:25] No, you know what's going on. Excellent. There's one, thank you for being the courageous one.
[00:07:37] So.
[00:07:38] You can.
[00:07:39] I know.
[00:07:40] You can shout, I. You can just speak really loud. Yes, I was just speaking very loudly. It's an American company versus non-American.
[00:07:53] Excellent question. So, is it is it the same in an American company or in a European company? So, in in some ways the question is difficult because there aren't really any European Big Techs or or or there are now more Asian Big Techs, so the Chinese are starting to uh to really pick up. Um, so in some ways, um, I'm not sure who who was this morning at Zalando at the at the at the talk that Henrich gave. Most of the big European tech companies are modeled after the Americans. So, the big European techs are actually very similar to the Americans. So, in that sense, there's very little difference because the Americans sort of came first and the Europeans then just sort of took a lot of the things they learned. And it's actually a bit like the PayPal mafia and this type of stuff. People who used to work at Microsoft or at Google or at Amazon went and then they started to work on all these other companies, and so they brought a lot of the stuff that they had learned, and and that's how they modeled this. China, very different. So if you go and work at Alibaba, I have a good friend who works at at Bite Dance. You're like, no, no, what what you see now is like this has nothing to do with the with the way that Bite Dance or or Alibaba are run, right? This is a very different life. Um, but in in the US and in in in Europe, tech the the big tech companies are more or less similar, booking, um, Zalando, these types of companies. They operate quite similar. Yeah.
[00:09:29] So you said that the culture quite different. Nice. How about this strong performance culture? in big tech companies and the one is the specific one. is that I know that management very likely will project, you can just wait.
[00:09:54] All right. So, performance culture or uh you you can just hang out and and and sort of like disappear into the ether because it doesn't really matter in the first place. Um, so if you watch Silicon Valley, it's definitely the second. Right? There's a company called Hooli, which is heavily modeled on Google and um one of the characters basically lives on the rooftop of that company and never seen anything, doesn't work at all whatsoever. I think the reality is is changing. So, so back in the days, so I worked at Google from 2005 to 2018. Um, back in the days it was definitely a performance piece. Um, it wasn't so much a performance piece because the managers asked for it, but it was driven actually from the people. So it was a very, very ambitious culture, um, and hiring was very specific to to look for people who had that sort of inner willingness and inner want to do well. And this is where you get the we'll change the world, we're working a ton of hours, etcetera, etcetera. Um, and management just literally had to channel the energy that was in the company in a way. That has gradually changed quite significantly. Um, I think Corona, the pandemic didn't help. A lot of people were hired. Nobody knew, it's like Matt did this before. Nobody knew where they were. It's like we don't really know what you guys are doing. And so people started to hide, and I think now, when I speak to people in Microsoft or or Google or at Amazon as well, it's like there's a lot more people that hide. And a lot more people go, it's like, ooh, this is still good money, and people don't really know where I am, so I'll I'll take it easy. And the culture in general has changed. So a lot of what I'm going to talk about is more from about 10, 10 years ago. Most of them have become more traditional big companies at this point, which is not surprising if you look at the market capitalization, amount of employees that they have today. No, this works sure. So one myth I hear a lot is that they these companies excel a lot because they attract the very, very best people. Like the less than 1% of engineers out there. Um, to what extent is this due to, you know, we have the best tech, we have, you know, you're working with cutting edge, like there's no better place to be if you want to build? Versus how much is it, there's so much money that we just pay you so much over the top? Or could it be somehow like 50/50? Again, it it depends a little bit on the time. I think it's a combination of a lot of different things. Um, at some point it was literally like, I need to be there just because of the hype, right? So people went and it's like. Like at Google specifically, it's like, it's like that that's sort of my life's goal is to work at Google because just how cool it is. It's like Amazon never had that, right? Amazon is not or Microsoft back in the early noughties was not a company that could go like, like we want the best and the brightest and the the fastest and all the the top graduates because Microsoft was not a sexy company, right? You didn't want to work on Windows code, um, you didn't you didn't want to spend time like digging in SQL server 5.0 and these types of things. So I think it has always been a bit different, but I think what unifies all of them in many ways is the scale. So the ability to work on products that really touch hundreds of millions of people at the same time. I think that has always been a very attractive draw for a lot of people. I remember when I it must have been 06 or 07, and we had network engineers and and SREs in the building. Um and and we all had TGIF and we all I remember this very excited SRE who had started like three weeks ago, talked to me about the fact that he now had root access on a thousand servers. And that alone was sort of that made his week as in like the the accomplishment unlocked in some ways. So there's definitely a piece of this cool tech scale piece that drew a lot of people there. Um.
[00:13:53] Yeah. Yeah, does that matter? I'm not sure if I'm going to get to my second slide, but that's okay.
[00:14:02] Yeah, so so one thing I heard, it's specifically said about AWS, so they are so performant because of the bright people that work there. But their way of working is absolutely not performant.
[00:14:16] So I I I know a few people at AWS, I can't confirm or deny this particular piece. Um, what I can and and there's actually a slide later. What I definitely can say is like if like a lot of people or some people believe that it's like everything at these companies works like clockwork, right? Everything is super efficient, super effective, everything is automated, and it's like people literally just like fly through tasks, not the case. Right? So the shiny veneer on top looks very good, but it's created with blood, sweat and tears just like any other company. Right? People like back like people spent insane hours, like between 07 and 11, I probably worked 65, 70 hours a week. Happily to be said. Nobody forced me to, right? It was super exciting, we launched ads into the world. It's like I was actually one of the the the launching people of Google Analytics in Europe. That was a fun week. Um, but it's like it was super exciting, and so people but it's like there was nothing automated. This is literally everything was sort of on the seats of our pants, like somebody needs to do this, it's like, okay, so we we would just copy paste by hand things from that database over into that database because you couldn't connect these two together. But it's like if it had to be done, it had to be done, right? And so in many ways, I'm always joking, my job as a product manager at Google, it was the shortest job description in the world. It was get shit done. Right? Whatever it would take, that was the job. And I think that's sort of what sits behind. So I can definitely see that AWS may not be an efficient organization or an organization that is sort of would you consider high performance, um, but. Over time, I think this has changed, right? So if you if again, if you heard Heinrich's talk earlier on Zalando and the way they do SRE, like Google invented a lot of SRE stuff for the world. And so, yes, they were a very high-performing organization in that part. But I'm sure there's other areas that weren't as high-performing in that case, right? But yeah. Is that the there's no magic. This is just hard work, like smart people, hard work and a lot of time invested into this. All right, I'm going to go try and go through some slides, but please feel free to interrupt me at any given moment. Um, this is one that I hear all the time. Ah, yeah. but but by the way, most people tell me it's like, well, yeah, yeah, yeah, Big Tech, but it's like, we're not Big Tech. We're not Google, we're not Amazon, it's like none of this applies to us. Not true, and that's part of the reason why I'm here. Because I do think to a degree, yes, some of it, certainly, but not in general. So this is one I hear all the time, is that working at Google must have been super easy because it's like you basically had no issues with money, right? Money was raining from the sky, whatever you wanted to do, you could do. Not happening. Right? It's like, I worked in Maps, I worked in shopping, I worked in ads, I worked in consumer operations, I have friends in Microsoft who worked in in Windows and in Azure and these things. I don't know, I I don't think I know anybody who ever had the luxury of not having to prioritize. Right? So the way we we would basically like this this is from maps, um, but it happened in shopping as well. Basically, or in shopping, we had 350 engineers in our Zurich office and we were doing all the B2B stuff for all the retailers, Walmart, etcetera, etcetera. Um, and every quarter, we would basically go, it's like, what should we be doing? And then all the teams came and said, oh, we could be doing this and this and this and this. And we like, okay, good. And we had an Excel list with about 130 items or epics in the in the in the more edge way. It's like that we could be doing, and then somebody looked at that and basically says, well, you get budget for about 29. And so we basically sat on 130 items and said, well, but I mean, this is, this is $10 million, this is an ROI of 215, this is whatever it is. And it's like, well, yeah, you got budget for 29, right? Go figure it out. And we were go in a room, all product people, all engineering leads, lock the door, and we we were only allowed to come out when we had figured out which are the 29 that we're going to do and which are the 101 that we're actually not touching, right? Not not up like, yeah, yeah, yeah, so we'll do as many as we want to. It's like, it was very, very, very clear, it's like how much money we could spend every time. The only thing. I I'll get to that. So, this one definitely. Busted. Certainly more money in heyday than for other things. Um, specifically for for fun things like Street View. I don't think many other companies would have financed something like Street View, but Street View started with a Volkswagen van with an open slide door, with a with a digital camera, one of the early digital cameras on a tripod, and they tried to figure out how fast can we make the damn thing click so that we can get like three streets put together. So nobody said, do Street View, but it was some people that basically said, wouldn't it be cool if maps had like this thing where you can drive through? And then they did a demo and then they went to Larry and he said, that is really cool. Now you get like 5 million, go to the next piece and show me that that one works, right? But it's like it they had to prove all the way down. But so for this kind of fun experimental stuff, there was bits and pieces, but it was never like, here's 100 million, just do street view, it's like, no, no, prove to me that it works out. All right. with a with a digital camera, one of the early digital cameras on a tripod, and they tried to figure out how fast can we make the damn thing click so that we can get like three streets put together. So nobody said, do Street View, but it was some people that basically said, wouldn't it be cool if maps had like this thing where you can drive through? And then they did a demo and then they went to Larry and Larry said, that is really cool. Now we get like 5 million, go to the next piece and show me that that one works, right? But it's like, they had to prove all the way down. But so for this kind of fun experimental stuff, there was bits and pieces, but it was never like, here's a hundred million, just do Street View. It's like, no, no, prove to me that it works out. All right. Nice segue. Um, primarily driven by bottom up ideas. Um, well, I'll give you the verdict.
[00:20:01] In MythBusters terms, plausible. Not completely true though. Because like Street View is a nice idea, like in Google terms, a lot of people know that Gmail was sort of a 20% project that spawned into Docs in the end. Um, big table and a lot of the big data stuff was stuff that was done internally first and people just developed sort of solutions for problems they had. And they became major projects afterwards. But the reality is that while that is a big part of it, like it is missing the fact that there's actually a top-down component to this as well. And a lot of people have ideas. It's really easy. Ideas are very cheap, right? We used to have this big ideas blot that had about 4,000 ideas on it at some point. Because people come and say, oh, I have this idea, and I have this idea, and it's like, I want to do this, and this could be really cool. The key to working with bottom-up ideas is to have somebody or some system that filters them down and picks the ones that make sense together, right? Um, and so this is, yes, bottom-up ideas is good and it helps a lot, but it just, it will fail if that's the only thing you do. You need to compare it. And again, it's like it was in a maths thing before, it's like different levels, right? So yeah, you can have a lot of people on level one that come up with ideas, but they only know their scope. Um, you need somebody at the top.
[00:21:30] Yes. Um, this is the piece that I mentioned before. So, um, it's not about the food actually. Um, there's a lot more about this. Yes, the food was great, the perks were nice. Um, flying business class occasionally was also appreciated. But I think the piece that's really, really critical here is that there was sort of a gentleman's agreement between Big Tech and the employees. We'll treat you well and you work your ass off. And that worked really, really well. And it worked for both sides, right? Because it was very convenient, if I go to the office, I don't have to think about where do I go to eat, I don't have to think where does my laundry go, I don't have to think how do I get from A to B. All these things were sort of assisted for me. And I could really focus on the things that I had to do, so I probably spend a lot more time thinking about business stuff. Then an average employee at a different company who had to go out for lunch and like do all these bits and pieces and then, etcetera, etcetera. So, yes. That's that that myth definitely is true. But it was not because Google thought, oh. It's like, we like our people so much that we're just going to give them food as much as possible. Um, it was a win-win, it was a clear thing. And there was also a trust relationship in here so that it wouldn't be abused and I'll get to that one in a little bit. Now, If I was in Germany, this would be a slide that is very dangerous.
[00:23:01] Um,
[00:23:04] I'll show you the verdict. Actually, no. Who thinks that this is this myth is true?
[00:23:15] Yes. I would I would agree. Um, so this is, this is definitely something that happens. Um, Big Tech does collect a lot of data. Um, and actually I think they created a lot of the big data movement is basically because the way that these companies have started to think about, Amazon is immensely good at this. Like the amount of experiments and data they collect on on their page is beyond imagination, right? If you look at Amazon's product page, it shouldn't exist. It's it's an abomination of design, it just doesn't make any sense, but it's been optimized to death and they know exactly when to make a change and make it prettier, performance goes down, right? So all of these types of things Big Tech has, um, has pioneered in many ways. Now, where I have a bit of an issue, um, in this is about the privacy piece. Because I know for a fact that like most of these companies spent an insane amount of time and effort trying to make sure that this is not an issue. Google went to the point and said, who are the most privacy crazy people in the world?
[00:24:18] Oh, the Germans. It's like, good, we'll put our whole privacy team into Munich. Because if they think it's okay, well then the rest of the world will certainly be totally fine with this thing, right? So, yes. They do collect a lot of data for a lot of different reasons. They don't generally do it to be evil or mean or or to cause harm with it. And they spend a lot of effort to make sure that it works out. It's like the amount of paperwork you have to go through to get to data at Google, on personal data at Google, is so large that nobody does it because it's just a pain in the ass. It's like, I'd rather build my product without any of that data, is like it makes my life much better and the product doesn't suffer from it too much. All right, and this one we already had, so I can skip this and make back some time. It does not work like a well-oiled machine, right? Occasionally you get glimpses of excellence, you go like, oh, amazing, we figured it out. And then, like, six months later something happens and everything that you did is broken and then you have to start from scratch again and it gets like. I worked two years in figuring, trying to figure out the geo analytics world. And I and we were doing like logs analysis on on Android and it's like, it was a mess. It's like, literally we were digging through server files. So it's like, nobody had done this before. It wasn't set up, it's like, we had to invent the whole thing and this is 2013 or something like this. This is not this long ago.
[00:25:45] Sorry, say again. they had to engineering to build it and then in the end I think they developed a lot of things over time in that sense. Um, and and I do think that obviously benefits. But I think sort of the principle behind it and this is this so I'm going into the second piece, the principle behind this is actually that you want to be very careful where you invest. And that is something that I see also in your question on European companies, um, that is something that I see a lot less in in in non-bigger tech companies. It's like the willingness to invest in something like this, which is really a long-term thing, right? Like we literally spent three years and a bunch of engineers on building a logged system for the the mobile applications for maps, because it was impossible to figure out what somebody wanted to do on a phone. We couldn't optimize for anything. So it's like, okay, this is going to be, this is going to be expensive in that sense, but we have to do it before we develop the product. And we just waited with developing the product until we had the data infrastructure in place where we could say, now we know if the navigation has been better or worse.
[00:26:52] We launched a feature, are we adding value, is this now better than it was before? Previously, we literally didn't know, right? We would look at it and it was like, oh, I don't know, I like it. It seems to be fine. My mom is a fan, it's like, ship it. But I mean that's not very sustainable. Okay. I'm skipping this because, um, we had a lot in the beginning, which is great. Um, so part two is breaking down the secrets. Um, and I'll try and use a metaphor for the next couple of slides and there's more text on the slides, uh, which you get, I think by the way. Feel free to take photographs, but like, I think you'll also get them. So, building products is a little bit like going to the moon.
[00:27:40] Well, okay, fine. It's not quite the same as going to the moon, right? But what I like about this piece is like it is very unpredictable. It's like, when when Kennedy said we're going to go to the moon, it was pretty clear on what he wanted to achieve, it was absolutely not clear on how to get there. And making products is exactly the same thing, right? It's like because you're dealing with technology, technology changes all the time, now more than ever. Like we're literally seeing a whole new technology sweep through the landscape, everything you thought of was two years ago was was fact, is not fact anymore. And so, in the same way that these people had to reinvent parts of the rocket and parts of the things all the time, because things changed around. The same is true for software. And so, in some ways, this is actually um very related, and the reason why this is so important in my opinion is because,
[00:28:37] again, a difference between the US and America in general, Europe and America in general. Europeans tend to like predictability and they tend to not like risk. They tend to like, what is the three-year plan and where are the flowcharts, right? And if you're building something like maps or a rocket to the moon, it's like there is no three-year plan. And there are no flowcharts because you're going to places where nobody has ever been before, and so you're making up the flowcharts on the way. And so this is sort of the thing. And I think this is the piece specifically that I'm going to try and focus on. This is what Big Tech has figured out really well, how to operate in an environment that is uncertain. And that you have to invent through the things that you're doing, you basically invent your own environment. And that is something that a lot of a lot of companies shy away from. Um, a lot of managers don't like the feeling, like I'm not sure where this is going, I don't know what's going to happen six months from now. I don't have a roadmap necessarily. That's tough, right? And it's outside of our human comfort zone in in many ways. And so, yeah, I'm going to try and go through some things that always apply. And so, not all these things will apply to all of you. I know that, right? And some some of you will say on some of the things, like, yes, sure, sounds great, never going to work. Fair enough. That may absolutely be true, right, depending on which company you work for, depending on who you what your role is, some of these things will not apply to you.
[00:30:15] I brought a few more. My hope is that all of you find at least two or three slides. Where you go like, okay. That's something that is true, that applies to me and maybe I can do something about it. And if you want to talk about it afterwards, I'll be out in the sunshine for a beer. I'm happy to go into details. This is low on details, talk to Matt if you want cool like canvases and these types of things. He definitely has some of those. Uh, we, I have them as well, it's just like I don't have enough time. All right. So, number one that you need when you go to the moon or build a maps application, which has never been done before, or or any other software where you're not 100% sure what's going to happen, is you need a plan and you need to tell it to people. Right? Um, and and there's a couple of things. So, I'll only focus on the big green things, right? Somebody needs to set overall strategic guidance. Kennedy said, we're going to the moon, we're not going to Mars. Same idea, we need a rocket and sort of fly and fuel and all that. But we're going to the moon. And he did a televised speech to the nation and said, we're going to the moon, so everybody knew about it, it was no mistaken, this is what we're doing. That happens surprisingly little. Right, I work with a client at the moment, and it's like, it's literally the boss and the team. And I work, the boss is my my counterpart and he's like, well, like, I've been saying this and doing this and say, I don't know, nobody nobody seems to to act. And I go to the team and the team is like, we have no idea what he wants. It's like, he's never told us what we're supposed to do. Right, yeah, we have like there's this thing and this thing and he talks a lot, but it's like, he's never I haven't understood what we're about here. And then he's like, well, but I've been speaking about this all the time. It's like, so both sides sort of feel they're not properly addressed. Um, while the the only secret is to say, they need to talk to each other more. We get to that one as well. Goal setting, it's like, Kennedy did this as well, by the way. It's like, by this year, we're going to have this, by that year, we're going to have this and by that year, we're going to land on the moon. So somebody, and again, this is sort of the top-down piece from the from the bottom-up slide, somebody needs to say roughly how fast are we going to do this? Um, because if that doesn't happen, then nobody knows really where we're going to go. And the third is resource allocation, talked about this as well. Somebody needs to say, how much money are we going to put down for this, right, this is the Street View piece. Yes, you're going to get 5 million, that's the goal I want to see, and our goal is to map the world with Street View. And if you have that set of these three things,
[00:32:52] everybody sort of has the framework and understands what are we here for, why are we doing all of this?
[00:33:00] Now, the second thing is that you build teams, right? And there's a lot of a lot of material about this. I personally like team topology a lot. But like everybody gets their mileage out of different things. But it's like structuring the organization based on your plan is critically important. And you can call it value streams or you can it doesn't really matter, I don't really care what what piece you you want to use. But the important thing is that each team knows exactly why it is a team. That's the clear mission piece. You are making the engine, you are making the part of the cockpit where the pilot lies in, you are making the windscreen. Whatever it may be, it doesn't really matter. But it's like, you are creating the cameras that can photograph out of the window at at least a thousand times a second. Whatever it may be, the team must be very clear. And ideally it can do this in autonomous ways. Like we we we won't get rid of dependencies.
[00:33:56] But we can minimize them and then manage them. And this is in my opinion, if you if you, this is one of the top three things that Big Tech has understood, like how to cut teams. Into autonomous units that can run on their own, because that makes teams fast, right? If you if you let them operate in autonomy, then they become really fast because they never have to go and ask. Asking means waiting. Um, waiting means time lost, the more you wait, the more you ask, the slower you get, the less you have to ask, the faster you get.
[00:34:27] And last point, retain a little bit of balanced decision-making piece because a team won't be able to decide on everything, right? Occasionally, there will be things that the team can't choose. Then you need to sort of escalate to higher levels and figure out, hm, do we do this, do we do this, it's like, yes, we figured out how to make the camera, but it costs 10 million. Can we have 10 million? Somebody needs to decide, yes, you're going to get 10 million or you're not going to get 10 million. For this.
[00:34:55] This is the second most, so in my top three, this is the second one. It's like, trust is existential in order to do good work. Um, you can call it trust, you can call it psychological safety, uh, there's a lot of ways that you can describe it. But in the end, if people don't trust each other, if people don't believe that the other person in the work relationship is on their side and wants the same as they do, it's like they won't move a finger without explicit incentives, right?
[00:35:26] But if you have trust, if you have a team that that understands we're working on this together, we have the same goal. You did this for me yesterday, you went the extra mile here, I will do the same for you. Right? And the only way you can do this is through interactions. And this is my gripe with a lot of the frameworks out there. They all rely on writing things down. Personally, I could not care less if a ticket is in a Jira backlog or not. Unless I have spoken about the same thing with the person who's going to do it, it doesn't matter, right? When have you last written a strategy, handed it to somebody and went like, here, that's the strategy, please read it and then act on it. It doesn't work. It's the same thing that my client has, where it's like, well, but it's all written down, here's the slide, it's like, well, the slide doesn't help because people don't understand what's on the slide and you've never spoken to them about what's on the slide. Only speaking and interaction is going to get you that level of relationship and trust. If you want to co-create strategy, bottom-up, top-down, you need to talk to each other. You can't write down the ideas and then send back, oh, we rated all your ideas and we're going to do those five, why, who decided, what have you been doing, it's like, did you smoke while you made this decision, it's like, you have not explained this to us.
[00:36:41] Interaction, communication beats process and writing down things. That doesn't mean you should never write down things. Last point, occasionally you must write down things. Nice this morning in the Zalando talk, like like playbooks for for incidents for example. You absolutely want to write down things occasionally. But a lot of frameworks today focus on writing down things and sort of passing things around, and I don't think that necessarily works.
[00:37:09] Like literally we ran we ran Google Maps on docs and spreadsheets for 10 years. It's like no ticket management system, no nothing. It's like everything in personal communication, and if you had to, you wrote it down in the simplest form possible with the least overhead that you can possibly imagine, and you could still share it. All right, this one you was like, I don't need to talk about this too much, I think, to this audience. But this is still surprisingly difficult. It's like, do not talk about the things that need to be done, but talk about the things that you want to achieve through that. I don't care which feature you built, right?
[00:37:45] I care that we're going to the moon. If you make the front window pink tinted, yellow tinted, or rose tinted. I don't care. But don't make 10 10 front screens, um, just because it looks good if you make 10 front screens, right? Pick one, and when we do one, we have a front screen and we can continue onwards. So it's like, it's important to always try and talk in what is it that you want to achieve. And that goes well with the autonomous teams, because the autonomous teams don't need to know anything else than what's the outcome that we want to achieve. And they need to know the plan, so where does that outcome fit in, and then now I can make decisions in that sense, right? So, outcome orientation, um, what that comes with is course correction. Um, if I'm being told,
[00:38:30] build the feature this way, and then this, and then this, and then this, once I'm on the journey, I'm stuck, right? I have committed. It happens all the time. Sold to the client these seven features, it's like, otherwise they won't sign the deal. B2B problem, happens to me probably about five times a year.
[00:38:45] In in discussions with customers or or clients, it's like, yeah, we already sold these six things. So they're on the roadmap. And it's like, do do they make any sense, what are you achieving with, well, we sold them, so so now we have to make them. It's like, no course correction possible, right? You're you're locked into this. Now something happens, AI shows up, another client pops up, you're helpless. It's like, you've committed on this and this is what you have to do. Agile is has nothing to do with this, business agility has nothing to do with this. Because you literally locked yourself into an output that you now have to make regardless on how useful that may be or not. I hope I'm preaching to the choir. I think the audience probably agrees. Um, the last piece that's very good is like if I outcome, and this is empirically proven and it definitely, um, is one of the reasons. That I worked 70 hours for many years. It's like, I felt responsible for my outcome.
[00:39:45] I knew that is what we need to do, that is what should happen at the end. It doesn't matter how I get there, but I want to get there. Because it's my outcome and I take pride in that outcome. I don't take pride necessarily in the shitty pieces that we do on the way there, some of them are very dodgy. But I want to make sure that Street View looks as good as it possibly can, right? Or because, I know Russian. It's like, I actually rebuilt the Russia maps. It's like, our outcome was, we want to beat Yandex in quality. That was for two and a half years, that was our goal. We beat Yandex on quality after two and a half years. And the VP occasionally came around, like, how's it going? It's like, 60% there. He's like, okay.
[00:40:27] And that was it, right? He didn't go, what did you do, like how are we on the house numbers, what happens on the satellite imagery, it's like navigation quality. It wasn't necessary, we knew the plan, we want to beat Yandex in quality, that's the outcome. And everybody was committed to do that because it was our outcome. that street view looks as good as it possibly can, right? Or because I know Russian, it's like I actually rebuilt the Russian maps. It's like our outcome was we want to beat Yandex in quality. That was for two and a half years, that was our goal. We beat Yandex on quality after two and a half years. And the VP occasionally came around and said, guys, how's it going? It's like, 60% there. He's like, okay. And that was it, right? He didn't go, it's like, what did you do?
[00:40:31] Like, how are we on the house numbers, what happens on the satellite imagery, is like navigation quality. And it's like, it wasn't necessary. We knew the plan, we want to beat Yandex in quality. That's the outcome. And everybody was committed to do that because it was our outcome.
[00:40:49] Back to the myth.
[00:40:52] I think they they did invent a lot of things and this there's actually a famous quote. from the founder and CEO of Netscape. I always forget, I think his name is Jim Barksdale. Very, very famous, he says, if we have data, we make decisions on that. If we don't, we make decisions on my opinion. And so that's what data actually does to you. I personally don't like data driven because it sounds as if the data tells you what to do and that's not really what should happen. I like data informed, and I combine this with the conversation piece and the trust part. Data should inform the conversation and in the conversation you make decisions and then you have trust and buy-in across everything. Because then everybody understands, the data said this, we discussed this, we made this decision. Now we have a plan and we have an outcome, you see where I'm going, right? This all sort of neatly fits together if you apply all of these together. Um, you need to spend a bit of time, the first two are sort of prep work for this. First, you need to have data, that's not always easy. And second, you need to know what to do with it, so you need to be able to read data and and interpret data. Um, and every time I see somebody doing quarterly goals and put CSAT against it, a little piece dies of me. Because CSAT doesn't move in a quarter. Especially if you launch your feature at the end of the quarter, like how on earth are you going to have moved CSAT with that feature if you launched it on the 23rd of March, right? So, CSAT generally takes about 80 to 90 days in order to really, it depends on volume a little bit. But it's like, it's a terrible metric for quarterly planning. Way too many people don't understand that, so that's what I mean by data literacy, right? So first you need to have the data and then you need to know what to do with it and how to use it. This is the last one, I promise. And then we're going to go to the takeaways. And this is my third biggest one. So it's like, that is the third piece and this goes again to the European versus US comparison. It's fine if you make mistakes. We're flying to the moon. We don't know how it works. We're going to screw things up along the way, occasionally. It's impossible not to, right? That's the only way that we can do this. If we don't try it out, how are we ever going to find out? Like Marie Curie didn't sit in her laboratory when it's like, I'm going to now discover radium. It's like, I'm going to do this and this and this and this and this. No, she probably failed about 20, 30, 40 times on the way there and eventually went, whoa, look at this. This is amazing. Like, we will move on with this, right? So, And and there's a few things that has something to do again with the predictability and the flow charts. So you operate a bit outside of flow charts. And I think it's important that you set a frame in which you can do these things. Like, allow teams to take calculated risk. That's important. Don't bet the farm on something, calculated risks, clear budget. Yes, you get 5 million, prove out to me that Street View is not a complete pipe dream, but that it actually can add something and could be a cool addition. If you do that, we'll continue. If not, we'll only lost 5 million. That's okay, that's in the budget for experimentation. And that that's the bottom one, right? So, ideally there is some sort of a budget for experimentation. It does it need to be 5 million for Street View. It could literally be 10% of your team's capacity in a given time period to play with something. And there is this very, very nice framework that I always keep in mind is Eric Schmidt introduced this like 70, 20, 10. 70% of your time should be on the core of the business. 20% of your time should be on things that are adjacent to the core and can extend that, 10% should be the wild stuff. It has nothing to do with what we do as a company, but ideally invest 10% in crazy things that may or may not fly at all whatsoever. And if they don't fly, well, they don't fly. But at least you've you've you've done your part there, right? And the last piece and this is something that I sadly I hear again and again and again. It's like, if I make a mistake, I'll be fired.
[00:45:07] Similar similar thing as as as what I mentioned with this other client. They said, so they decided 12 months ago they're going to launch an app. I said, why are you launching an app?
[00:45:18] Don't quite know, but we're launching an app. And so now they're late. And they're late because they realize they don't actually have all the prerequisites for launching an app. They don't have the data connections, they they don't have engineers that are very experienced in building an app, they don't have product people that know how to make an app. Um, they don't have basically it took them a year to figure out is like how do we build an app. So and now the app is late, and they realize now we have all these things and now we've realized, we don't need an app. It makes no sense to have an app. It's like, it's just not what we should be doing. And I said, okay, so the obvious example, the obvious choice here should be it's like, kill the app, right? and work on something else. He said, I'll get fired. I'm like, why would you get fired if you say we're wasting our time? This is a 10 person team, right? We're wasting 10 people's time on building an app for which the whole team believes we don't want or need the app. There's no value in this app. He said, we'll all be fired.
[00:46:17] I'm like, you should be promoted. If you come out and say we should not, sunk cost fallacy is a terrible thing. People go, it's like, well, we spent so much money on this already. It's like, yes. Well, That doesn't make any sense, right? If you threw a million dollars into the send, and somebody said, well, what are you doing? And they say, I have another half million. It's like, well, throw that as well because I already threw 1 million, right? It's like the other half doesn't matter either. It's like, no, that doesn't mean you can do so many things with that half million. And so, like learn from your mistakes and are not don't don't be afraid to sort of own up to them. And go, it's like, that was a fuck up. It's like, it's like,
[00:46:55] maybe maybe maybe we've got unlucky or or maybe we just didn't make a good choice. It doesn't really matter, right? So if you can, it's like, here's a little thing that I really love, it's like, if you can implement something in your company that's called like a fuck-up Thursday. And you just invite people to come and talk about the biggest mistakes they've made, maybe not in that current role because they may get fired. But maybe in other companies before or other experiences they have. That's like a nice little thing that you can do to sort of start doing this this thing. Or Hendrik talked about post-mortems earlier today, that's also a great thing. Right? Same, not same TJ, but TJ a couple days, a couple weeks later, it's like, somebody came and said, I brought down Google search. And he was so excited. For him it was an achievement, right? And literally, he had brought down Google search, I think for three minutes or something like this, nothing bad. But it's like instead of going, it's like, oh my god, right, I'm going to be fired, this is like, no, because 50 people had come and and and saved the day. And it was a 20-page postmortem document and he's like, I literally caused 15 processes to change because of that one mistake I made, and now the whole system works so much better. And I brought down Google search, right? He was not scared, he was not afraid. He didn't feel bad about it, he knew it was a mistake and it was his mistake. It was like, okay, fine, I'll never do that again and Google will never do that again as well. It was amazing, it's like, it's burned into my brain because I was like, this doesn't sound like a great thing that you're telling me, he's like, no, I really did.
[00:48:30] Alright.
[00:48:33] Takeaways.
[00:48:37] Shake break, no, everybody's still with me? Yes, good.
[00:48:44] I'm I have one more slide that looks similar to the ones before, but it's changed.
[00:48:53] Um, and I think that's that's that's sort of my first takeaway, sort of a meta takeaway from these things, right? Like, the only constant in the world is change.
[00:49:06] Arguably possibly said by a Greek philosopher, unclear if that's actually the case, but it is the truth. And especially in software and technology, things are changing and they're changing ever faster. I mean, I am around, I've been around for the block for a really long time, AI is bigger and faster and more disruptive than anything I have ever seen. And so the chances that in five years things are the same way that they are now are very, very, very, very low, right? So this is continuing to happen. And so the things that I tried to talk about and I think the the things that Big Tech is really good at is managing against that pace of change. And being comfortable with the fact that there's no flowcharts. And there's no three year road map. And the fact that next month, next quarter, next year, we may have to rethink what we're doing and we may have to throw away the stuff that we thought was good last year. And we may have to kill the app because it really doesn't make any sense.
[00:50:06] Um, so yes, and these are the things, right, constant refinements, keep your structures adaptable. Google re-org'd me every six to nine months.
[00:50:14] Not not not for the topic that I did. But like the team structures, right? Like we we we always slightly adapted things like because we wanted to keep teams autonomous and able to move fast to remove dependencies. Teams were not there for three years. People worked on the same topic for three years, so they built the main expertise, but they weren't in the same team setup necessarily. But everybody trusted each other anyway, so it didn't really matter much who you worked with. You see how these things all kind of nicely And yes, kill your darlings or your apps. Or whatever it is that you think you are spending way too much time and money on in your current place. It's like go and challenge it, right? Do we really need this? Does it fit into the plan? Right, do we need a unicorn on the rocket, right? Is it making us go to moon faster or is it just for shits and giggles? These ones I just left here, um, because they're sort of nice little mantras that I use for myself. Um, I'm not sure if we mentioned all of them. Oh, and I took out 70, 20, 10, um, that was on there as well. But yeah, what problem are we solving? What's the plan? Are we going to the moon, to Mars or are we just sailing to Australia? Um, make sure your teams are are structured in a way that you don't ship the org chart. Um, that you don't just, like every team sort of does what it's meant to do, but none of the teams know each other. Um, take risks, ask for forgiveness, not for permission. It's like, you can read, I don't need to read this to you.
[00:51:51] Um,
[00:51:54] And then these five things. Uh, very briefly, I know normally you everybody says there should be three. I really couldn't make, uh, Gemini cut this down to three, it insisted on it being five. Um, so I left it at five because I think the five are actually pretty good. Um, Big Tech is not perfect. It's like, has never been. Probably getting worse from what I hear actually. Um, but it it's always been hard work, um, and and a lot of grinding in order to get there. Um, the combination of guidance and adaptivity is very important. Somebody needs to say where the plan is and then the organization needs to be able to move and navigate within that plan based on whatever is important and what comes up. So the combination is the part that's really important. You want empowered and aligned teams. They should work together against the plan, but on their own they should be able to run as fast as they can possibly run because that's really the way that you speed up everything. Communication and outcome, these two things make people feel and have a purpose. And believe in this is what we're doing and I understand why, and I know that you are with me on this thing and we're doing this together. Right, we're doing this together. Um, and the last one is don't be afraid to take risks. Don't be afraid to take mistakes because you are navigating a landscape. That is anything but predictable and so if you try and squeeze predictability on it. You are way more likely to run into problems than if you accept the fact from the beginning that there is no predictability. It's like, I hate 12-month roadmaps.
[00:53:37] I think they're utterly useless. Like that doesn't change the fact that every executive I have ever worked with is asking for 12-month roadmaps. So you have to find sort of the medium in the middle, but where I can, I avoid them because I do I cannot predict what's happening in 12 months, right? Now, next later, if anybody knows that sort of product, um, method is brilliant in my opinion, it's like the best roadmap framework there is. Thank you, Janna Barro. Um, so that would be another one of these tiny little frameworks or methods that I can give you guys with, um, to try out if you aren't doing that yet. And with that, it's 6:30 and that that means I think I am supposed to stop.
[00:54:22] Uh, we have some time for three questions.
[00:54:28] I'm not stopping you from drinking beer, I'm not, I'm not offended if you choose to take the sunshine over questions.
[00:54:47] The question, uh, one. Uh, please wait for the capitation.
[00:54:59] You mentioned killing the darlings. Isn't uh, Google X known for their uh, like one of their key metrics is number of projects they kill? Is that is it, is that a myth or is that true?
[00:55:10] No, that is not a myth. Um, actually Google is one of the ones that kills in public most, I think, I I would argue more than others. Microsoft has done that as well, Microsoft killed Zune for example. Um, Amazon has just killed Fire, um, after 12 years of trying to make a viable Android solution that is Amazon branded, they have accepted the fact it's not happening. Um, and so they killed the fire line. Um, but Google, Google is known to to look at this more than others actually. So reader went and and there's a whole bunch of things that that actually get killed. Um, they're still not amazing at it. Um, in my opinion, even they could be better, but yes. So X definitely had sort of an up or out, uh, sort of methodology, either you make it in a couple of years or we're killing you regardless on how far you have gotten, yes.
[00:56:07] Cool.
[00:56:08] If anybody else uh, wants to chat, I'll be outside, hopefully still sunny, um, happy to talk and discuss any other things you have. Thank you very much for your attention.

Transcript