Blog Alexis Monville (en)

Author: Alexis

  • Exploring Leadership and Open Source with Maria Bracho

    Exploring Leadership and Open Source with Maria Bracho

    Some leadership environments reward authority.
    Open source rewards influence.

    That is the quiet power behind my conversation with Maria Bracho, CTO for LATAM at Red Hat. Her story is not only about technology. It is about what leadership becomes when you cannot force outcomes and must instead create conditions where people choose to build together.

    Open source explained through ramen

    Maria offers one of the most tangible explanations of open source I have heard, and it starts in Japan.

    She tells the story of instant noodles and the decision to share a method with competitors so an entire ecosystem could move forward. Companies could still compete on flavors, but they standardized the foundation. The result was not only industry growth, but global adoption.

    This is the open source logic in plain sight:

    • share the foundations so everyone can build
    • collaborate on the hard common problems
    • compete on what makes you unique

    In software, that foundation can look like Linux. The toppings can look like products, services, packaging, and the experience you deliver.

    Leadership across geographies shapes the leader

    Maria has led in multiple regions, and her lived experience shows in the way she describes leadership.

    She contrasts the directness and energy of Latin American communication with the subtlety and collective orientation of Japan. She also points out something important: culture is not only what people say. It is what the language allows and what the environment encourages.

    For leaders working across geographies, this is not a “nice-to-have” insight. It changes how you listen, how you build trust, and how you create alignment.

    Taking on the hard problems

    There is a pattern I recognize in Maria’s career: she takes on work that many people avoid.

    Her explanation is surprisingly grounded. It is not a heroic narrative. It is a mix of perspective and appetite:

    • perspective from where she started, which makes “hard” feel worth attempting
    • appetite for the satisfaction of moving something difficult forward
    • a belief in persistence, learning, and collaboration

    I also noticed a subtle leadership trait here: she does not let the full size of the challenge paralyze the first step. She moves, learns, adapts, pivots, and keeps going.

    Product leadership without authority

    One of the most practical parts of the episode is when Maria describes her transition as a product manager.

    Before Red Hat, she could write documents that said “the system shall do X, Y, Z” and expect engineering to execute. In open source, that model collapses immediately.

    Instead, she had to learn to:

    • influence communities rather than command teams
    • co-create with customers and partners
    • collaborate with competitors and coopetitors
    • iterate in public until the outcome is good enough to ship

    Her conclusion is sharp: the ego-based model is expensive and slow. The collaborative model is hard work, but the outcome reaches production faster and fits reality better.

    This is a leadership lesson many product leaders need:
    If you struggle with engineers, it may not be a communication problem. It may be an authority mindset in a system that requires influence.

    Recruiting as a leadership responsibility

    Maria treats recruitment as part of her job, not as a task delegated to HR.

    She designs the hiring process intentionally:

    • aligning the future direction of the team with the profiles she seeks
    • involving a strong panel that challenges candidates and challenges assumptions
    • seeking diversity of perspectives to strengthen the team, not just fill a seat

    Her standard is simple: the time spent recruiting pays back when the team becomes stronger, more cohesive, and more catalytic.

    AI, the Red Hat way

    Maria does not avoid the AI topic. She embraces it with a clear framing: Red Hat’s approach must be authentic to its mission.

    She highlights RHEL AI and InstructLab as signals of a serious commitment to AI through openness, community, and access. The emphasis is not only on features, but on democratizing the ability to work with models, adapt them, and keep control of where data lives.

    Whether you agree with every detail or not, the leadership principle is consistent:
    new technology becomes durable when the ecosystem can participate.

    The closing advice: work hard, stay authentic, keep learning

    Maria’s advice to her younger self mirrors the way she leads:
    work hard, stay true to what you believe, stay open to feedback, and keep learning.

    It is not glamorous.
    It is also how influence is built over time.

    References for you!

    Here is the Transcript!

    Alexis: Welcome to another episode of Le Podcast on Emerging Leadership. I’m your host, Alexis Monville, and today I’m thrilled to welcome Maria Bracho, Chief Technology Officer at Red Hat LATAM. Maria brings over two decades of experience in steering multinational technology initiatives and mastering the art of leveraging cutting edge technology to drive business growth. Maria, it’s wonderful to have you here. Could you start by sharing how you typically introduce yourself in professional settings?

    Maria: Hi, Alexis. It’s a pleasure to be in your podcast. I am Maria Bracho. My role at Red Hat is as Chief Technology Officer for Latin America. And I partner with our customers, communities, and our teams to create better experiences. And shape the vision of Red Hat both [00:01:00] in as our technology, but also with communities and move the world forward, hopefully with open source technologies.

    Alexis: Hmm, Maria, for many, Red Hat is synonymous with open source, but there are also many in our audience who may not be familiar with either open source or Red Hat. Could you explain what open source is and perhaps share a bit about Red Hat?

    Maria: Sure. Absolutely. In the context of software, open source not only means having your code available for others, but it means sharing it in a way that others can also use, modify depending on open source licenses, but also create it with open source communities for open collaboration and definition of the goals that you want to pursue together And, and also be able to listen to multiple ideas that move the technology [00:02:00] forward.

    Alexis: Would you have something to explain that in more, I don’t know, more tangible way for our audience? Thank you.

    Maria: Yes, absolutely. So I have a few examples from personal experience, as you know, I have lived in different places, but I’ve also worked in these different countries that I’ve lived. And more recently I lived in Japan for the last four years. And. It’s fascinating to me to going to a new place, but also live, work, share the customs especially the food as well.

    And I came across this example by going to the Cup of Noodle Museum in Yokohama. That’s the city I lived in. And this was one of like the highest rated places. Places to go for newcomers and visitors. And of course we never went because we just thought it was a tourist trap and we didn’t feel like tourists, but we had time for a family to come visit.

    [00:03:00] And we went there as I was listening to the story of ramen, it really felt very familiar the way we. Talk about open source software. Have you ever had ramen? Alexis,

    Alexis: I had some, yeah, of course. And yeah, I’m, I’m very curious about how, how some sort of noodles would speak about open source, the way you spoke about open source just before. So yeah, yeah. Enlighten me, please.

    Maria: so I’m not talking about the ramen. So you go sit at a fancy restaurant and they come in hot and ready for you. I’m talking about the workhorse of ramen. The ramen that are hard and that are essential. staple for university students, anybody with an end of the day or after party snack, middle of the night hunger pangs, et cetera.

    These are the flash [00:04:00] fried. Ramen noodles that you can then rehydrate using hot water. So it’s the simplest form of, of cooking a super delicious and satisfying meal. Again, not necessarily the Michelin star experience, although there are some Michelin star ramen cup of noodles in Japan. So anyway, the story starts with Momofuku Ando who like post war Japan was sitting in with many looking at lines and lines of people trying to get this hot cup off of ramen and understanding that in the provinces or inside of the country, it was hard to get access to food.

    And wheat had become one of the new crops to come into Japan. So noodles was a new thing that, that was coming. But access to food was problematic. So he didn’t want people to sort of stand in line hours to get food. He wanted to devise a method to preserve the noodles, to have those [00:05:00] noodles be more accessible.

    And here’s the part where the invention may have come from him or may have come from someone else. But he was sharing this problem with his wife as she was cooking tempura shrimp. So she was flash frying the battered shrimp to come up with a delicious meal. She told him that what happens with when you flash fry Shrimps is that it takes out all the moisture from the batter, and then it makes it a little bit more shelf stable.

    So she was able to get the shrimps ready and then get them, let them last for hours, if not days. And then you put the flash fried tempura noodle. back into a soup, it will reabsorb some of the water and rehydrate and made it delicious to eat. Obviously, if you let it soak for a long time, it won’t be delicious.

    But anyway, the whole point was this flash frying method. And after trying many other methods to [00:06:00] preserve the noodles some of that were not effective causing some stomach intoxication and food poisoning because they wouldn’t. Last that long, Momofuku Ando try this particular method, and he was very, very effective with it.

    So he noticed that this allowed the noodles to remain shape shelf stable for months, and it would preserve them and all you have to do then later before eating was to rehydrate it with hot water. So access to hot water was a lot easier than just to have an entire kitchen to to prepare meals. So this game this gaming clutch, he started being very, very famous for it, his business started to grow.

    There was a lot of interest and then he was looking at his competitors. And seeing them sort of stumble into problem after problem to try to get to the perfect way of preserving the noodles. And he had this, this thought that [00:07:00] it wasn’t just about him or his business, but it was more about Japan and saving the people and helping feed the country.

    So what he did next was sort of an odd move even for a collective thought society like Japan. So he met with all his competitors and started sharing the recipe. He said, Hey, this is how you should preserve the noodles. Japan is huge on on food regulation and sanitary procedures to preserve food as well as other multiple processes.

    So they were sort of eager to get this new method going and they would still compete on the flavor that you add to the soup, but sharing how to preserve the noodle. was something that helped them all move forward. It also helped them standardize on other partners and vendors that would help bring more flavor [00:08:00] to the cup.

    So they would partner with a company that made the size of the cup. So regardless of the noodle that you were selling, everybody had the same cup. So the cups became cheaper to acquire and then to resell. And then. It also made it possible for vendors that would serve other packet flavorings and MSG and other you know dried shrimps are added or dried corn or other toppings that are added to the mix.

    So all of that lower the price and increase the accessibility to the point that you can find this type of ramen. anywhere in the world. So even though his ambitions were for the collective of Japan, it ended up

    influencing it globally to the point where you can have the same noodles today and they are curry flavored.

    They have specific flavors for different regions. If you go to Thailand, you’ll find them with like lemongrass and other things. So the idea was starting small, thinking about the [00:09:00] good and the collective and moving a whole industry forward and then seeing where you can get. So I guess Momofuku Ando

    Alexis: last

    Maria: didn’t even think that that he was going to be able to, to influence so widely and his influence lasted even to NASA because the space program also has these noodles in space.

    So that made me think about. Our influence in the work that Red Hat has done with Linux. And it was a little bit about not just the improvement or moving one company or one technology, but it was more about being the right way to share and think about the collective and the power of what can we all accomplish together and and move us forward.

    You know, we have RHEL now in space as well. So right along with the noodles. So that’s what made me think about parallelisms with open source and the places that I’ve traveled.

    Alexis: That’s a very beautiful way [00:10:00] to explain open source and explain the benefits of it. And explain also why competitors can collaborate on something that even becomes a standard like Linux that can run everywhere, even at Microsoft. And, that’s something very exciting for people.

    So I hope it will help people understand role of open source. in an ecosystem and why competitors can absolutely cooperate on building the community, the future standard, but still compete on the toppings. Maybe even a little bit more of that. So Maria, you are, you have an impressive background with leadership role in different geographies, and you said it, Japan, but you worked in the U.

    S. and now Latin America. How have these experiences shaped your leadership style and what unique challenges and insights could you share with us? ,

    Wait, 

    Maria: Yeah, I also spend time in France. [00:11:00] So well, some of the things unintentionally, my career has sort of been that way. I have found that not only being in different geos, but actually living there understanding the language, the culture, the way of work. Also. It has influenced myself.

    So I also think that have left a mark on me.

    Alexis: wait, wait, wait. You lived four years in Japan and you’re telling us that you speak Japanese?

    Maria: I am not by any approach of the imagination fluent in Japanese. No way, even though I have given it my best efforts. I’m absolutely not fluent, but there’s a lot more of the culture that is. That is the language. And if you think of, I mean, coming, from Latin America where it’s a different way of communicating or sharing information, of collaborating it in itself is very direct and open and exciting and somewhat loud in Japan [00:12:00] is very more.

    Very much more. It’s quiet. It’s subtle. It is a lot more thinking about the collective rather than the individual. And that has been a great sort of compare and contrast and two different two different forms of the spectrum. And then in North America, that’s really where the bulk of my career has been.

    So corporate America has been sort of the staple of how I have moved. Working at Red Hat has been the space where we think more global in terms of community and collaboration and the power of open source. So that’s how I feel much more at home at Red Hat with open source communities because it does think about the The power and the good of the collective but also being very direct at proposing ideas and also sort of challenge each other and, and challenge the status quo.

    That may be [00:13:00] very French with et cetera. And and so, so I find that that that has been a great, a great space to use all of all of what I have learned in different spaces. And yeah, I’m very, very happy to be here. Sort of back in Latin America, where where I started my my career and my preparation in a region that is growing sort of year after year, not just for Red Hat, but for many other companies, a region that can benefit very much so from open source and the innovation that happens elsewhere, but also that happens in LATAM.

    A geo that has many challenges, both political economical challenges, but has a lot of people willing and able to try. A lot of the spirit of the underdog and a lot of the spirit of trying new things and not being afraid and sort of like there’s nothing to lose kind of way. So I love being in that space.

    If you think about it, [00:14:00] Latin America is sort of the startup of the, the rest of the GEOs, where, where North America and Europe would be like the most established. And, and then APAC comes in with very niche offerings and then take over spirit of taking over the rest. Latam is very much the startup where, or incubator where many ideas happen.

    Alexis: It’s very interesting. I’ve observed you working on topics that probably nobody wanted to take. Nobody wanted to take that challenges. And and it seems after sometimes people were realizing that, yeah, you were doing really great. Can you explain how it works? Can you explain how you are doing those things?

    Maria: Well, I have, I have been for a long time with an attitude of both being naive to the challenge, but also I’m just happy to be here. So I started my career in Venezuela very much a third world country [00:15:00] where it was really, really hard to get into, into very competitive university and have access to collaboration with.

    Research into institutes all over the world. So I was very lucky to be in one of those. And then anytime that I look back to, to where I was and the place where I’m from, no longer exists as I knew it. So I think anything extra is, is gain. So I usually do take on the hard, difficult assignments because I have found so much The reward of getting something done that was very hard or complicated.

    There’s nothing like it. So I’m usually chasing that that thing or that same feeling of, wow, we moved, we really moved the needle. We really made an imprint here and we changed it for the better, left it better than [00:16:00] when I did it. Came in and then I also selfishly I learned a lot. I learned a lot and I learned that I could do it.

    So I’m more emboldened the next time. So, and I’m still naive to the next challenges that I that I take. So, but I know that persistence and hard work. And collaboration and, and the spirit of learning from others really moved, moved me forward. So I’m happy to do that.

    Alexis: Yeah, but there’s something with that idea of being naive that I have trouble to understand. Can you tell me more? What, what happens to people that they start really working with each other, collaborating really well that’s not, I have trouble connecting that, connecting that with being naive. So tell me more about that.

    Maria: Well, maybe the, the exact word is not just naive, but it’s not letting the big challenge stop you. Because, and not [00:17:00] letting, not seeing the full picture also stop you, but understanding that And this is very true with open source. Understanding that if you influence And collaborate with a collective and you continue to move forward, you can help shape the innovation.

    You can help shape the future. And that is that is very consistent, even if the beginning, you don’t know exactly how hard it’s going to be or how long it’s going to take or how difficult the challenges, the external challenges are going are going to be. But understanding that through being open and persistent and open to learning and growing and changing direction, pivoting as well.

    Hard work pays off.

    Alexis: Yeah, it’s a, it’s, it’s very interesting because I have I’ve, I’ve heard over the years, a lot of product managers [00:18:00] in tech, having troubles to interact with engineering teams and getting what they wanted and and now you work in open source and of course you cannot tell open source or the open source communities to do what you want so it seems that it sounds like a no problem for you so tell me more about that maybe other product managers can use that

    Maria: No, that, that was a lesson hard learned. I think that my first few months at Red Hat, so I joined over nine years ago as a product manager, and I was a product manager at another company where I just created PRDs and MRDs and product managers wouldn’t know what that is. But it’s basically a document that says the system shall do X, Y, Z.

    And that’s really what I focused on, understanding the market, talking to customers and then I would give that to my engineering team and wait [00:19:00] until they tell me they need any clarifications and just give me a timeline of when it will be done based on a timeline that I gave them. So the ego was quite big Alexi, and then landing in an open source company where, you know, that would be read.

    And it’s like, well, this is. This is a nice looking document. Yeah, we’re not doing that right now. You need to go talk to the communities, et cetera, et cetera. So I was like, what I need to, I need to influence outside my own company. You mean these are not, these walls are not really walls. These are more like lines in the sand that I can cross at any time, embed myself into other customer problems, really work with them, co engineer, figure out exactly their use case.

    And then also collaborate with competitors and coopetitors To again, together, understand the problem and come up with a solution and then [00:20:00] iterate and iterate on this. That was new for me. It felt like an enormous amount of work. It felt like nothing I had done before. It felt like my ego was nowhere to be seen, and I was just in the mud wrestling to get going.

    However, the outcome after that. Is that the piece of code, the design, the documentation, whatever outcome that we had created and co created and co engineered together, went to market kind of right away, it made it to production in that moment. A new sense of, wow, this is the way kind of became upon me and I don’t think I can go back.

    I mean, I’m not interested in the ego of thinking that whatever I said goes, because I also frankly had a lot of situations where whatever I said And then I had to pay a third party to [00:21:00] try my product and tell me the feedback. And then even with that feedback that I had to pay to get, it didn’t actually resonate with customers the way that I wanted it to resonate.

    So. I’m not ready to have that feeling ever again. That was a huge waste of time. So I, if I have to work hard, iterate with communities, wrestle with competitors, competitors, partners, customers, To to really move technology forward and move entire industries forward. That’s a hard work that I am grateful to have because the outcome and the feeling of accomplishment is It’s, it’s unlike anything I had ever experienced before.

    Alexis: I love it. And I can see how it led you to, to, to become a chief technology officer for, for that, that geography you are in because yeah, you’re able to be a very comfortable with the [00:22:00] technology, talking directly with engineers. Inside your company and outside of it, and and really wrestling with different customers or competitors or to finally agree on the size of the cup, the noodle cup.

    That’s pretty cool. I love it. Could you share a little bit about Your approach to recruitment and what strategy you find most effective to, for assembling a team.

    Maria: Wow. This is, this is great because I just recently had two recent hires that I’m extremely proud of of having found them. I think I take recruiting with, you know, this is my job, not just outsourcing it to the, to the HR team or the talent acquisition team or another recruiting firm or whatnot.

    I think that understanding. Where I would like a team to, to be and fit and to see if those folks [00:23:00] are also going to be great fit for the current and existing team and whether they’re also going to come and catalyze the team and sort of bringing new perspectives based on where we want to go is also very, very important.

    And so I, I reach out to, I think like anybody else does like to my network. I reach out within the company, outside of the company. And then I usually try to find a diverse group of folks to help me with a, with a strong panel that can not only challenge, the applicants, but also challenge me in, in what they expect my team to be.

    So I also try to bring them in, in the recruiting phase. If we’re going to, to be collaborating in the future, because, because of this specific thing that I shared before, like we’re bringing somebody in, we want, we want them to feel valued, but also add value and help them grow. So I, I invite the rest of the team and I was happy to say that I also tasked them with with the opportunity to recruit or just to [00:24:00] bring and help shape the positions that we’re in.

    So I take more time than I would want, I think recruiting, but I think it usually pays off. I’m very happy about the team I’m putting together.

    Alexis: I hope they will listen to the episode to, to hear that you’re saying it out loud to the world. That’s pretty cool. Looking at what, what are some of the key areas of focus for you and your team at Red Hat.

    Maria: I’m in the field. So as a CTO I’m still part of the engineering organization. So what we are looking for are moments to, to co engineer with customers. So beyond just. The products that we have today, the communities of open source that we engage with today, just find and understand use cases of where the industry is going.

    Whether it’s, I don’t know, telco, FSI financial services, or, or even communities focusing where other, other industries are, are engaging with health and sciences [00:25:00] or insurance companies, et cetera. We try to. Come together and be a trusted partner where this new technologies, they can understand this new technologies and how it can affect or move the needle for their business and then creating spaces or other sometimes they’re competitors, sometimes not competitors, but they’re in the same sort of vertical.

    for customers to come together and see how they’re using our technologies and other technologies in addition to that. Because that way they don’t feel so sort of lonely or alone following their own technical trajectories, but they can build a roadmap that aligns, not just with their business, but understanding other adjacent business.

    And so, And we help create that community between customers as well. Because we know this is sharing ideas in this way is, is the way to move, to move things forward. And now selfishly that also helps us validate and [00:26:00] understand the, where Red Hat is going, where we should be investing, where we see spaces, where it makes sense for us to invest more maybe or, or ways in where, in which we can, we can be effective to, to other businesses.

    Alexis: Hmm. And you are a CTO and will you, will you say anything about AI or, we are in, in the midst of the hype of ai, so there is, there’s nothing you are doing about it.

    Maria: I have been planting seeds about that since the very beginning. So even with the ramen story, I, I also planted the seed and made a allusions to, this is pretty much how Linux started. And you know, we made recent announcements just last week. We had Red Hat summit in Denver. We have some of those presentations up in YouTube that release some new, some new cool products and, and others that are in sort of tech preview, but One of the, one of the big announcements was RHEL AI, which [00:27:00] naming a product as a product manager is one of the hardest things to do.

    But for us to name RHEL AI, RHEL AI, it could have been another name, right? But for us to call it. Red Hat Enterprise Linux AI and attach AI to that known and trusted brand means that we’re very serious about moving into the AI space. And I think we’re doing it in the most Red Hat way in some in a way that is very authentic to the mission and vision of the company.

    Of being catalyst in, in communities of customers, partners, collaborators to, to move it forward using open source. So we also made an announcement around an, a new invention called instruct lab, which helps modify large language models, which is a, which is really a novelty because any other technique to train a model has been done like rag, for example.

    at the inference stage, [00:28:00] but having the ability to influence a model itself to change the actual model is something that was not accessible to regular humans. You needed a data scientist to, to be able to do that. So I really love that we’re democratizing the access to, to models were influencing I think in this case, IBM to open sort the granite family of large language models that, that is huge.

    And then having a way. For anyone to modify a model a from their computer. Like you have a laptop. You can do this. This is something that if we see the current models available, even if they have open in the name you don’t really know what’s in there. Having the ability to have a models where the code is available Openly cited with the data that it was trained on.

    So you know exactly what it was trained on and the ability for you to use it, modify, train it with your data [00:29:00] and keep all of that private is is very, very interesting and compelling. So we’re really hoping to catalyze this industry and really excited to. to what’s to come. Kind of same as the beginning, like Momofuku Ando just trying to preserve a noodle.

    We’re starting small and we are eager to see where this can go. Understanding and being not a hundred percent naive, but a little naive to what it would, where that would go, like how far it can go. And all we have going for us is, It’s just the experience that we’ve had with Linux. So that’s really, really exciting, Alexei.

    I think we’re at an inflection point here and I’m, and I’m happy to be part of it.

    Alexis: I love it, Maria. And that will be my last question. What advice would you give your younger self?

    Maria: Wow. [00:30:00] Ah, you know, I have a 16 year old daughter that I give advice to. And she looks just like me and likes things just like me. And sometimes I wish she wasn’t so like me, but the, the advice that I tell her is sort of the same thing that I, that I did is just work hard, continue to be authentic to, to who you are and what you believe and.

    And then be open to be open to feedback, open to learning. You will find places where you can continue to, to shine and places where you can continue to learn. And hopefully that will be leading you to a fulfilling and happy life.

    Alexis: I love that. I continue to explore. That’s beautiful. Thank you, Maria, for having joined the podcast today.

    Maria: Thank you. It’s a pleasure. [00:31:00] 

  • Mindsets for the Future

    Mindsets for the Future

    Leading in a Non-Linear World: Building Wellbeing, Strategic and Innovation Mindsets for the Future

    Traditional linear leadership models are increasingly ineffective. Jean Gomes’s book Leading in a Non-Linear World provides a comprehensive guide to understanding and adopting new mindsets necessary for thriving in our complex environment.

    Embracing Complexity and Uncertainty

    Making Sense of the World

    Leaders must question their assumptions and seek new perspectives in an era characterized by volatility, uncertainty, complexity, and ambiguity (VUCA). Gomes emphasizes the importance of challenging our sense of certainty and embracing the non-linear nature of today’s challenges. This mindset shift is crucial for leaders to adapt and thrive.

    A Decade-Long Journey

    Gomes has been exploring how our brains and bodies interpret the world for over a decade. His research delves into the interplay between physical sensations, emotions, and cognitive processes, highlighting the need for a holistic approach to leadership.

    The New Science of Mindset and Self-Awareness

    Understanding Mindsets

    Mindsets are more than just attitudes and beliefs; they are the fundamental ways we make sense of the world. Gomes defines mindsets as the interplay between physical and emotional states, assumptions, and perceptual frames.

    Physical Self-Awareness

    Gomes underscores the importance of physical self-awareness, known as interoception. This involves tuning into bodily signals, which provide valuable information about our internal state and the external environment. Leaders can enhance their decision-making and emotional regulation by practicing techniques like body scans.

    Emotional Granularity

    Expanding our emotional vocabulary is another critical aspect. Most people use a limited set of words to describe their emotions. Leaders can better understand and articulate their feelings by developing greater emotional granularity, leading to improved self-awareness and interpersonal effectiveness.

    Building Mindsets for the Future of Work and Life

    A More Human Mindset

    Gomes advocates for a more human mindset, emphasizing radical self-awareness and well-being. This mindset fosters a deeper connection with our physical and emotional states, enabling healthier behaviors and improved decision-making.

    The Future Now Mindset

    Leaders often struggle to balance short-term performance with long-term value creation. The future now mindset encourages leaders to think strategically about the future while delivering immediate results. This involves recognizing the interconnected nature of various time horizons and aligning efforts accordingly.

    The Experimental Mindset

    Innovation and adaptability are crucial in a non-linear world. The experimental mindset, rooted in a test-and-learn approach, allows organizations to innovate rapidly and effectively. Gomes highlights the importance of creating environments that support continuous experimentation and learning.

    The Open Mindset

    An open mindset values diversity, inclusivity, and collaboration. It involves seeing the potential in others and fostering an organizational culture that embraces change and continuous improvement. This mindset is essential for building flexible and adaptive teams.

    Practical Applications and Conclusion

    Deferred Judgment

    One practical technique Gomes discusses is deferred judgment. In high-stress situations, taking a moment to calm the body’s physiological responses before reacting can prevent defensive or aggressive behaviors. This practice allows for more thoughtful and constructive responses.

    Collective Mindsets

    Building collective mindsets involves fostering a shared understanding and emotional connection within teams. This approach enhances collaboration and helps teams navigate complex challenges more effectively.

    Continuous Learning and Adaptation

    Ultimately, “Leading in a Non-Linear World” calls for embracing continuous learning and adaptation. By developing new mindsets, leaders can navigate the complexities of the modern world with greater agility and resilience.

    Jean Gomes’ insights offer a robust framework for modern leadership. By understanding and embracing these principles, leaders can create resilient organizations that thrive amidst uncertainty and change. As we face unprecedented challenges, the ability to lead non-linearly will be a critical differentiator for success.

  • Engineering Leadership at Scale: Navigating Complexity and Change with Tamar Bercovici

    Engineering Leadership at Scale: Navigating Complexity and Change with Tamar Bercovici

    When engineering systems grow large enough, leadership stops being about control.

    That is one of the strongest messages from my conversation with Tamar Bercovici, VP of Engineering at Box. Her team supports a platform used by tens of millions of users and stores massive amounts of enterprise content. At that scale, leadership becomes a different discipline.

    From individual contributor to organizational leader

    Tamar describes two major transitions in her career.

    The first was moving from individual contributor to manager. Like many engineers, she found the transition awkward at first. The work changed. The definition of success changed. The challenge was no longer writing great code, but enabling others to do so.

    The second transition was even bigger: moving from managing teams to managing organizations. At that point, leadership is no longer about direct influence. It is about creating the conditions where many teams can succeed simultaneously.

    Each step required Tamar to rethink what she was accountable for and how she measured her own impact.

    Scale changes the leadership game

    One striking aspect of the conversation is the ratio between scale and team size.

    Tamar leads a core platform organization of under 200 engineers supporting one of the largest content stores on the web. That reality forces a very specific leadership approach: you cannot control everything, and you should not try.

    Instead, leadership becomes about context. If engineers understand why something matters and what outcome they are aiming for, they can make good local decisions without constant oversight.

    Change is the job

    Large-scale engineering leadership, as Tamar puts it, is largely about leading through change.

    Infrastructure migrations, cloud adoption, evolving customer needs, new technologies like generative AI – none of these are static problems. They require continuous adaptation.

    Tamar emphasizes three principles when leading change:

    • Make the change your own, even if it was not your decision
    • Be transparent about why the change is necessary
    • Avoid both sugarcoating and venting

    Leaders must own difficult messages while still providing a credible path forward.

    Clarity beats control

    One of Tamar’s most practical insights is deceptively simple.

    If you stop someone in the hallway and ask them what the next milestone is, they should know the answer.

    That level of clarity allows leadership to scale. It enables teams to move independently while still rowing in the same direction. Without it, leaders are forced into constant intervention, which quickly becomes impossible at scale.

    Risk is not the problem

    Another powerful reframing Tamar offers is about risk.

    Risk is not a sign that an initiative is wrong. Anything meaningful carries risk. The real leadership work is to name the risks explicitly and then de-risk early and continuously.

    That can mean prototypes, pilots, staged rollouts, load tests, or customer design partners. Whatever the form, the goal is the same: reduce uncertainty before it becomes failure.

    This mindset turns large programs from fragile plans into adaptive systems.

    Innovation on top of foundations

    After completing a full cloud migration, Tamar’s teams are now focused on optimizing and innovating on top of a more consistent platform. The emergence of generative AI is a natural fit for Box’s role as a content platform.

    What stood out was Tamar’s realism. AI is both hype and substance. The technology is moving fast, best practices are still forming, and customer expectations are evolving in real time. Leadership here is not about having all the answers, but about learning faster than the environment changes.

    Advice worth remembering

    When asked what advice she would give her younger self, Tamar did not point to a specific career move. Instead, she spoke about reducing the emotional weight of decisions.

    Careers, like software, are iterative. Choices are rarely irreversible. What matters is making a choice, committing to learning from it, and adjusting when needed.

    At scale, leadership is not about perfection. It is about intentional progress.

    Here is the transcript of the episode

    Alexis: Welcome to Le Podcast on Emerging Leadership. I’m your host, Alexis Monville. In today’s episode with Tamar Bercovici, we’re diving into the art of leadership within the tech industry. Tamar, VP of Engineering at Box, has led her team through groundbreaking transformations, bleeding the art of building high performing teams with the science of developing innovative technologies.

    Join us as Tamar shares her journey from a software engineer to a visionary leader at Box, revealing her strategies for building teams and steering her team towards continuous innovation. 

    Welcome Tamar. Could you share how you typically introduce yourself?

    Tamar: Hi, it’s wonderful to be here. My name is Tamar Bercovici. I’m a VP engineering at Box where I lead the core platform. So at Box we’re building out the, the content layer for the enterprise and the core platform is [00:01:00] the underpinning of our product. So a lot of Distributed systems type challenges high scale challenges, but also the backbone for the product.

    So thinking about what the right abstraction layers are been at box for 13 years. Yeah, that’s me.

    Alexis: Excellent. So what drives your passion for technology and leadership?

    Tamar: I think the technology space is just fun. You know, it’s a really unique combination of, hard, interesting, intellectually challenging problems combined with a lot of customer empathy and, and human empathy and, and a lot of creativity. So I think there’s just a really unique mix that we get to, to think about problems from a lot of different angles and a lot of different perspectives.

    And then leadership is something that I, You know, at some point in my career, I shifted into a managerial position and sort of as an experiment, but I think I learned [00:02:00] that there’s something very compelling about teams and how you bring people together and align their energies and their passions and their talents to accomplish a goal together.

    Like there’s, there’s, it’s, it’s a really unique type of challenge in and of itself, how you do that. But then there’s also something very. I think gratifying of working in that way. It’s something that I like. So you know, being in a leadership position is enables me to create that for myself and for my team.

    And it’s something that I’ve really enjoyed over the past years.

    Alexis: So me a, give me a sense of the scale of what we are talking about. That’s what are, what is the size of your team? And on the other side of how many users do you, do you have? How many customers are we talking about?

    Tamar: So, so box focuses primarily on enterprises on businesses. And we have, you know, businesses all over the world as customers all different industries, all different sizes from, you know, very small companies to. [00:03:00] Some of the largest organizations that we have and and then the users are the employees at that in those companies that have seats at box, plus, you know, individual users, of course, as well.

    And so in terms of the scale of users, it’s in the tens of millions, but some of the interesting elements of box platform specifically is that is the scale of of content that we store on the platform. So we’re probably leading one of the largest just content stores on the web and that has a lot of interesting challenges just It’s straight up in the, in the storage itself and uploads and downloads and managing copies and encryptions.

    And it’s just a, a very sort of unique challenge in and of itself, but then also the system and the product and the, the, the metadata around that, that enables the product experiences an interesting scale challenge as well. 

    Alexis: With users in the tens of millions what is the size of the team managing that core platform?[00:04:00] 

    Tamar: so we, we run a relatively lean engineering team, I think, for the scale of the company. My team specifically on the core platform is just under 200. And that’s again for Sort of all of those core parts of our infrastructure, the storage infrastructure that I mentioned our data stores eventing systems search index metadata stores and then kind of the, that core backbone business logic layer.

    So recently AI platform thrown in there as well. So a lot of those, those sort of fundamental components and then within box engineering more broadly, we have. Teams that are focused on just kind of the pure infrastructure layer to make sure we have the right environment to operate our systems.

    As well as of course, all the teams that build out the product experiences themselves.

    Alexis: I still find that incredible that that’s, that’s a very small team compared to the challenges. But yeah, that that’s perfect. That’s really good. Tell me more about your, your transition from an individual contributor [00:05:00] to a management role and the.

    pivotal moment in the decisions to do that.

    Tamar: I joined box as an engineer and I was actually coming off of finishing up a PhD in theoretical computer science and my goal at the time had just been to, you know, To kind of get back into industry, get back into a startup environment. I had a previous experience working at a startup company before, and I really like that sort of somewhat more chaotic and flexible and dynamic experience, and then also just being.

    Very connected to the business and the customer and what we were trying to build. So that was sort of what I was looking for. And I specifically wanted to get into web, like box is actually the first web company that I worked at. And after joining as an engineer, my first biggish Project was around building out the initial scalability layer for a database infrastructure.

    And one of the interesting things that you go through in an early stage company, you sort of shift from [00:06:00] very generalized roles to incrementally sort of more specificity in, in what you own. So I joined a, a six person backend engineering team that kind of owned all of it. So, you know, at any given time you had one person who happened to be working on the storage infrastructure, one person who was working on databases.

    Right. But it wasn’t like, There was a lot of specialization there and it was fine. It was appropriate because it was a much simpler stack. But then as the company was scaling and we had to scale out the, the infrastructure to support that you’re now building more complex systems. There is more value in investing in those systems, but then also as you make those investments, you increase the complexity.

    You now need people who specialize in the system. So you sort of go through this process of all of a sudden having differentiated teams. And I have a team that owns storage and a team that owns databases and so forth. And so again, I had kind of Thank you. Been a part of that, that database project that [00:07:00] shifted it from very simple, single database to a somewhat more complex infrastructure.

    And I was faced with that decision point of staying on the technical track or, or, or trying my hand at management. And I debated it a fair amount. And I, I feel like actually it was hard to get good advice on this. It It felt more consequential at some level than it should have, because honestly, this is the kind of decision that you can undo.

    Like I’ve, I’ve I’ve had multiple people who sort of shifted into management and then decided at some point that that was no longer the path they wanted. They went back to being individual contributors, but that experience actually gained them a lot of, I think, insight and perspective on what it takes to, To lead an engineering team to have a healthy engineering team.

    And so it enabled them to be better engineers, I think. And then there was also a lot of muddiness in the conversation around is engineering management, a technical role or not. And I wanted to stay in a [00:08:00] technical role, but at the end of all of that debate I decided that management was going to be a bigger departure from what I had done thus far.

    And I was curious. I wanted to try it out. And I think that initial transition is awkward for almost everyone that, that I have ever either talked to or, or, or managed who was going through that. And definitely for myself, it, you need to redefine what it is that your job is and how you. Assess your success or failure in your job.

    I think it becomes a little difficult to separate yourself from the people on the team that are doing the work. So it took a little bit of time. But I think once I wrap my head around that, I found that I really enjoyed it because again, it let me. Look at the same set of problems, but from a more kind of well rounded, multiple angle type perspective.

    And I just I like that. And so I, I [00:09:00] really enjoyed it. I felt like I was learning and growing and decided that this was the right path for me. And I think that that was sort of the first big transition. And then I think that the second big transition is sort of further on when you shift from managing teams to managing organizations.

    And again, understanding what that requires and how you need to shift what you do and what you hold yourself accountable. It’s again, to some degree, a different role. So I’d say those were sort of the two big, big moments.

    Alexis: Excellent. Thank you. Thank you for that. Can you discuss some strategies you’ve employed to foster a thriving engineering culture?

    Tamar: I think. This is the 1st thing is you have to work at a company as a leader in particular. If you’re not the CEO who’s sort of setting this tone for everyone, if assuming you’re working. You know, for someone, I think it’s important to find a place that your values [00:10:00] align with that, that, that the culture aligns for you, because as a leader, it’s a, it’s really important that you are modeling and reinforcing that culture and those values.

    And so finding a good place to work is, is I think key so that the investments that you’re making are synergetic with what’s happening more broadly within the company. And then I think a lot of it is. At the end of the day, all of us, no matter what our role is, I think good employees, like what do we want?

    We want to be challenged and have opportunities to grow. We want to work with a good group of people and we want to make sure that we’re having impact, that our work matters, right? People, if you’re working at a company, then, then, then generally you want, you want that to, to be somehow contributing to what’s important.

    You want to understand why, what you’re doing is important. But by the way, because any job has. Sort of the less interesting parts, like any job, every, every single role, every single job has the exciting bits, the challenging bits, the, the, the, the flashy [00:11:00] ones. And then the more run the business aspects or the more the, the less exciting aspects.

    And so you have to be somehow motivated by the importance of what you’re trying to accomplish. And so as a leader, Yes, making sure that it’s, it’s sort of that good, good cultural DNA and that you’re reinforcing that within the team and setting that tone from, from yourself, but then making sure that the team has a, a compelling thing.

    Goal or set of goals to strive for and that people really understand how what they’re doing fits in with what we’re trying to accomplish as a business and have that context. I think that’s how you get engineers or whatever role they’re in at the company that understand what we’re trying to accomplish and can hence.

    Make better localized decisions, feel more empowered, be more engaged and actually deliver better results. So fundamentally that alignment of what we’re doing to business impact, it [00:12:00] sounds sort of straightforward, but I think it’s, it’s very foundational to having a healthy culture and engaged engineers.

    Alexis: And so I assume that as a, as a lot of people managing through through changes is can be challenging. Do you have examples that you can share that, and that were really challenging and what have you learned through those, those examples? Hmm.

    Tamar: I think a lot of leadership is. Chain leading through change, right? You know, our organizations are very rarely stagnant, right? There, there’s an evolution of what we’re trying to solve for, what our goals are, what’s challenging, what isn’t you know, ups and downs in the business that you need to contextualize as well as just, you know massive challenging projects that you need to lead the team through that, that cause big shifts.

    So it, whether it’s sort of a. More of a like corporate context or a people, [00:13:00] HR or process or technology at some level, a lot of that is what we do as leaders. And I think there are some commonalities for all of those, which is you have to understand whether it’s you sort of driving, like you’re making the decision and causing the change or whether you are.

    You know, you have to make it your own, you have to understand why it is that we’re doing what we’re doing, why do we need to make this change? And what are we solving for so that you can be very transparent with the team? Again, change is always uncomfortable, we all have a little bit of that reaction of like, oh, you know, what’s happening?

    I feel unsettled. I don’t know where this is going. But having that context on why we are dealing with this problem and, and what we are. What we are hoping to accomplish sort of transparency, even if it’s about the challenging things is really important, but then in particular, if it’s challenging.

    You know, striking that balance of making sure that you’re, you’re not sugar coating and kind of glossing over [00:14:00] the critical parts, but then that you’re not over almost like over empathizing with the negative and effectively like venting or ranting to your team. Like you have to, you have to own the difficult message if it is difficult and then you have to.

    Show sort of why are you optimistic that we are going to navigate this change successfully? What do we need to do to make this work? What are your expectations of the team? And then everyone kind of understands, understands that context and knows how to approach it. I think specifically in the context of, of sort of, I’ve had the opportunity at Box for, for whatever reason to.

    To lead us through several sort of big infrastructure migrations, which are, you know, think, you know, very large scale efforts we had some that were sort of shifting. Between various on prem data center environments, which is still a quite complex endeavor to shift your entire infrastructure from one place to another.

    And then more recently, [00:15:00] we completed a sort of a full migration from all the workloads that we had on prem into the cloud. And that’s something where. You need everyone across all of their different services and, and, and, and tool sets and libraries and, and, um, corpuses to, to, to figure out sort of the right set of things to do localized while also having it be part of that, like overall migration cadence and how do you wrangle something like that?

    And so again, it’s, it has to start first and foremost with a. With a ruthless clarity of goal. Like everyone needs to know what we’re trying to accomplish and why. So that as they’re making localized decisions, they make them in a way that’s synergetic with the overall goal. There’s no way that you can go control every little last thing that, you know, hundreds of people are doing.

    Even 30 people, I don’t think that’s feasible. So definitely not a whole organization. And [00:16:00] so having that clarity of goal and then having even clarity of like, what are, if there are any sort of interim milestones that we’re trying to hit as a team, like really making sure that those are simplified to the point that people, if you ask them, if you stop them in the hallway and you ask them like, Hey, what’s the next milestone we’re working towards, they’ll know what that is.

    And that can give you the confidence that because we trust that we’re building a a high performing team across, across the, the, the floor, if people know. what they need to solve for, they’re more likely to be able to make those good localized decisions. And then it all kind of like connects together and you’re able to steer that, that unwieldy process to a successful conclusion.

    Alexis: Yeah. I like, I really like. How you framed it. It’s very interesting there’s the need to understand why we are doing something and to own it and to make it your own. That’s not, even if the changes is pushed on you in some ways at some point you need to make it your own. And and you need to make [00:17:00] sure that finally everybody knows why we are doing something and what we are aiming at.

    And there’s those intermediate milestones that we’re aiming for. That will really enable decisions by the people who are, who are doing the work. And I, I feel there’s a lot of things to connect there that are really important. I am capturing all of that.

    Tamar: Yes. Yeah. Yeah. That was a a great recap. I think it’s, you want to increase the chances that all the decisions that are being made, you know, you scale out by enabling people to make good localized decisions. And you do that through context and, and through that sort of drum, like the high level drumbeat and through a lot of communication.

    And then, you know, Of course, there’s, there’s more to this, right? You need to have some, some signals that you’re rolling up to tell you how things are going so that you know if a particular area is falling behind and maybe you need to dive in more like it’s, it’s never as simple as it sounds in, in the podcast.

    [00:18:00] But, but I do think that sometimes we almost like, Jump over that 1st part and start diving into the hard problems that we know exist. But then if you, if you do that too quickly, and you don’t take the time to set that overall context for everyone, you’ll, you’ll have more problems as you go along. I think maybe 1 more thing that I would call out in the context of any.

    And he’s sort of large scale change. They’re always risky in some way, right? Like there’s, there’s some element of risk on will we be able to successfully make this change and will it have the impact that we expect it to have? And I think sometimes people interpret the risk as a sign. That this is a bad idea, or that maybe we shouldn’t do this or they sort of make plans that assume no risk and then say, but this plan is at risk because there’s a lot that we don’t know.

    There’s sort of this kind of Handling of risk that’s maybe not what it [00:19:00] needs to be. And I think it’s important. And this is something you can do as a leader as well, again, to sort of frame that for everyone to take a step back and say, there’s nothing of value that is without risk. So the fact that there is risk is not a problem because we know that this is risky.

    We have to ask ourselves concretely, what are the risks that we’re concerned about? Right. And then once you’ve called out the risk, you make a plan to de risk. So it’s not about knowing everything. You sort of assume that as you’re going through this process, there’s an ongoing level of risk that you’re managing.

    But managing the risk is not just acknowledging that it’s there, but rather figuring out it. It’s usually about de risking as soon as you can, right? So is there a POC that I can do? Is there an initial test? Is there a load validation? Is there an integration point? What can I do to, is there a customer? A user study, a customer test, a design partner, like depending on whatever the project is, it [00:20:00] doesn’t matter if I’m rolling out a new process change, can I roll it out with an individual team to help them iron out the kinks?

    Like what is the risk of the thing you’re trying to take on? What are the ways it could fail? Actually spelling those out and then putting in place actions that help you reduce the risk of that happening. And at some level, that’s how you manage the program. And so if you have clarity of goal. And you have clarity of everyone within their own areas, de risking towards that goal.

    That is the best way that I know of to increase the chances of successfully hitting that, that outcome that you were hoping for.

    Alexis: I really love that that idea that there’s things that, you know, that’s good. You need to make sure that, you know, why, why you know them and there’s things that you don’t know, and then you need to conduct experiment and so that, you know, a little bit better, those areas you don’t know. I really love that.

    That’s that’s perfect. Thank you very much. Looking ahead What are some, some of the key areas of focus for you and your [00:21:00] team, and how do you plan to continue innovating 

    Tamar: I think there are some areas that are almost a constant, but that is a good thing. If you’re running any kind of large scale infrastructure platform system, you’re, you’re always thinking about, you know, Performance availability, efficiency, you know, all of those kind of fundamental foundational components.

    And the reason hopefully you’re always thinking about them is because the scale of the business is growing. The scale of the customers is growing that the types of. Especially in an enterprise context, the type of work they’re trying to do on top of your platform is becoming more sophisticated, more critical, and hence their demands of you are growing.

    So all of these are good signals. Like if you constantly feel like you have a More to do to, to keep kind of ahead of the business needs in terms of the scale at which you can operate, then that’s a [00:22:00] good sign. And so that is often and always a key focus area for us. I think in this year, in particular, after.

    Completing our cloud migration. There’s obviously a lot of optimizations and, and improvements that we’re now able to make by having everything in sort of this more consistent modern environment. So we have a lot of focus there. And then at the product level, we’re at a really exciting inflection point at the company with a lot of interesting momentum coming together, both from kind of macro trends, as well as just things that have been building up within box to, to really.

    Enable our users to leverage, to, to get value out of the content that they have on our platform in new ways. The whole sort of AI generative AI hype cycle that, that we’ve been in, it is a hype cycle on the one hand, but on the other hand, it’s, it’s It’s a real sort of kind of suite of technological.

    It’s [00:23:00] technologies that are building up for years, but they’ve sort of gotten to that point of capabilities as well as kind of market recognition where all of a sudden, it’s really compelling. And, and if you think about it, they’re, they’re very good with unstructured Content with, with, with human text.

    And what is, what is box, if not the platform where you put all of that data. So, you know, when this, when this was kind of exploding you know, around a little over a year ago, we were kind of, you know, we were all just as, you know, anyone who’s a technologist and following the field is like, wow, this is, this is so exciting.

     I didn’t think that we’d so quickly get to the point that, you know, things like the Turing test maybe need to be rethought in terms of what they mean. But then at the same time, we realized how relevant this was to our product and to our users and really thinking about how to completely shift the paradigm around what type of value you can get from the content that you have on Box.

    And it’s, It’s really interesting to try to [00:24:00] connect like the technological capabilities to solving real customer problems and delivering real value in a space that’s so emerging, right? There isn’t a paved path of here’s what, you know, successful use of this looks like. Here’s what the customer expectations are.

    You’re, it’s kind of, you’re figuring out all layers of it all at once. The, the underlying, excuse me, the underlying technology is, is just. Shifting so quickly and then the best practices on how to leverage that and how to build product from that are shifting so quickly. And then, and then what the customer wants and even how to price it like the whole thing is in a state of flux.

    And so it’s just been really fascinating this past year building out the foundation for that. And then looking forward, I think we just have a few really exciting ways in which we’re going to Continue layering intelligence through our platform to really enable new and compelling use cases.

    Alexis: Excellent. I love it. [00:25:00] So to close what advice would you give to your younger self?

    Tamar: it’s always hard for me to answer those questions because at some level, I’m a bit of an optimist and so I think even the challenges and the bad decisions that we make or, you know, the places where we derail a bit, I see the value of the learning from each of them. But maybe at some level, that is the advice to not.

    I think sometimes when you’re at the beginning of your career, a lot of decisions feel very consequential. It’s like, I’m now making this choice and this is like, this is going to be the trajectory of my life. And it feels. the emotional burden of that can, can feel high. And it’s true that , when you’re further through and you look back, you understand how each and every one of those choices built to where you are today.

    But that’s not to say that had you made different choices, you would not have Similarly, been able to have a [00:26:00] compelling path. So I think just like software development is a very incremental process, right? We’ve we’ve sort of collectively as an industry with the advent of web learned this process of iteration and making small changes and and getting it Data validation and then tweaking and adapting and adjusting.

    And at some level, our careers are no different, make a choice and then optimize for whatever choice you made. And if at some point it feels like that’s not the right thing, you know, make the next choice, but you’ve, you’ve learned something and get, as long as you’re intentional about what you’re doing and you.

    Apply your energy and you stretch yourself to learn and grow sort of with every phase then that even the ones that don’t go so well, I think end up adding another rung in your ladder to wherever that ladder is leading. So I think that the advice would be to not be too worried about those things and just make a choice and move forward and see where it takes you.

    Alexis: I love it. That’s a very [00:27:00] beautiful one. Thank you very much for having joined Tamar.

    Tamar: Thank you. Thank you for having me. This is great. 

    Photo de Jeremy Bishop

  • Playing to Win

    Playing to Win


    In exploring leadership and organizational strategies, I’ve often navigated the delicate balance of language and its impact on team dynamics and individual mindset. The concept of ‘winning’ can be a double-edged sword—while it inspires some, it might instigate fear or paralysis in others who dread the prospect of losing. This aversion to a win/lose dichotomy has led me to seek a more nuanced approach in my work and teachings. However, in the realm of strategic thinking, A.G. Lafley and Roger L. Martin’s “Playing to Win: How Strategy Really Works” employs the ‘winning’ terminology in a manner that is both effective and enlightening.

    “Playing to Win” delves into the essence of strategy, stripping it down to its most fundamental questions. Drawing from their remarkable turnaround of Procter & Gamble (P&G), the authors present a compelling narrative that strategy, at its core, is about choice—specifically, where to play and where not to play. This perspective is crucial; it emphasizes the strategic decisions about markets, segments, and categories essential for any organization’s success. Lafley, the celebrated CEO of P&G, and Martin, his close advisor and strategic thought partner, showcase through their partnership how leadership at the top, complemented by strategic advisement, can harmonize to make those pivotal decisions.

    Their framework pivots around five essential questions that guide strategic thought and action:

    1. What is our winning aspiration? This question centers on the organization’s purpose and the ultimate goal of its strategy. It’s about defining what ‘winning’ looks like for the company.
    2. Where will we play? This involves choosing the markets, customer segments, channels, or product categories in which the company will compete. It’s about focusing efforts where the company can achieve a competitive advantage.
    3. How will we win? This question requires determining the unique value proposition and the set of activities that will deliver this value better than competitors. It’s about identifying the company’s unique approach to serving its chosen markets.
    4. What capabilities must we have in place to win? This addresses the internal strengths and abilities the company needs to develop or maintain to support its strategy. It’s about aligning resources and capabilities with the strategy.
    5. What management systems are required to support our choices? This final question focuses on the structures, processes, and measures needed to ensure the organization can effectively implement its strategy and achieve its goals.

    Their approach to ‘where to play’ and ‘how to win.’ It’s a refreshing take that moves beyond the binary of winning and losing, focusing instead on strategic choices and execution. This methodology provides a blueprint for making informed decisions that align with an organization’s overarching goals and values.

    The synergy between Lafley and Martin exemplifies the profound impact of a collaborative leadership model. Their partnership at P&G—combining Lafley’s executive leadership with Martin’s strategic insight—serves as a powerful example of how high-level leaders and their advisors can work together to steer an organization towards its strategic objectives.

    In “Playing to Win,” the win/lose dichotomy is recontextualized as a framework for thoughtful, strategic decision-making. It’s a testament to the nuanced approach needed in leadership and strategy, one that I find both valuable and aligned with the ethos of seeking deeper understanding and effectiveness in organizational dynamics.

    With its focus on strategic clarity and actionable insights, this book offers valuable lessons for leaders looking to navigate the complexities of the business world. It reminds us that the essence of strategy is not the pursuit of winning for its own sake but making deliberate choices that propel an organization forward.

  • Trust, Excellence, Customer Delight

    Trust, Excellence, Customer Delight

    Engineering leadership lessons from Bruce Wang (Netflix)

    Some leadership philosophies sound good on a slide and collapse the moment reality arrives.

    Bruce Wang’s doesn’t. It is simple, grounded, and demanding. In our conversation, Bruce, Director of Engineering at Netflix, describes the three pillars he tries to balance every day:

    • build a trusting team
    • seek excellence and mastery
    • drive customer delight and value

    The tension is the point. You cannot maximize all three at once. Leadership is the ongoing practice of balancing them without drifting into extremes.

    Trust is not given, even inside the same company

    Bruce joins a new team at Netflix and starts with a clear assumption: people will not automatically trust him.

    Yes, reputation helps. But trust still has to be earned. He talks about building what he calls vulnerability-based trust: showing you are a person, not a role, and creating space for honest questions and challenge.

    One practice I loved: asking people who worked with him before to share “what’s wrong with Bruce” in front of the new team. It is a direct way to make psychological safety concrete. Not as a slogan, but as a lived behavior.

    Vision first, then structure

    Bruce describes a sequence that is easy to underestimate.

    First, get clear on what the team is here to do. Not the tech. The purpose. The customer value. The essence.

    Then, and only then, decide the team structure: the balance of managers and ICs, the domains, the diversity of the group, the shape needed for where you are going.

    If you start with structure before direction, you end up optimizing for today and paying for it later.

    The leader’s growth edge: letting go

    Bruce makes a point that shows up again and again when leaders scale.

    At first, you lead individual contributors. You are close to the work. You can shape direction through direct interaction.

    Then you grow managers. And that changes everything. You have to scale yourself through others. The hard part is emotional, not intellectual: letting go of being the center of the system you helped build.

    In his words: sometimes growing the team means letting go.

    Process is not the enemy

    Netflix is famous for “people over process,” and Bruce names a subtle trap: teams sometimes treat process like a dirty word.

    But deploying code is a process. Offsites are a process. Coordination is a process. The real question is not “process or no process.” It is: what is the lightest structure that helps the team do better work?

    Bruce’s approach is principle-based. Try something. Keep what works. Throw away what doesn’t. Do not force a framework just because it is fashionable, or because another successful company used it.

    He adds a useful warning: copying Netflix practices without Netflix context is risky. What works in one environment may fail completely in another.

    A failure mode worth remembering: the shortcut that breaks trust

    Near the end, Bruce answers the question I wish more leaders asked themselves: what are your failure modes?

    He shares a clear example: he moved too fast to present a vision, collaborating with one strong supporter but not building shared alignment across the broader senior engineering group. The result: pushback, confusion, and a hit to trust.

    The lesson is sharp: speed can look like leadership, but shortcuts often bypass the very collaboration that makes strategy real.

    If you take one line from this episode, let it be this: before you go fast, check whether what you are doing is a shortcut.

    Leadership as a humble gardener

    Bruce references Team of Teams and the image of the leader as a “humble gardener.”

    It fits this conversation perfectly. The job is not to be the hero. It is to cultivate the conditions where people can grow, do excellent work, and deliver customer value.

    Humility, curiosity, and continuous learning are not soft traits. They are operational requirements.

    References mentioned in the episode

    • Winning Now, Winning Later by David M. Cote
    • Team of Teams by Stanley McChrystal

    Here is the transcript of the episode:

    Alexis: [00:00:00] Welcome to the podcast on emerging leadership. I’m your host, Alexis Monville. Today, we are diving into the art of leadership in tech, building and sustaining excellence with our distinguished guest, Bruce Wang, director of engineering at Netflix. Bruce brings a wealth of experience from the intersection of tech, business, and team culture.

    His journey from a hands on developer to a leader focused on people leadership, culture cultivation, and mentoring offers invaluable insights into the evolving landscape of tech leadership.

    Welcome to Le Podcast on Emerging Leadership Bruce.How do o you typically introduce yourself to someone you just 

    Bruce: I’ll probably just say, Hey, I’m Bruce Wang. I’ve been an engineering leader for about 20 plus years two time founder. And currently I’m a director at Netflix.

    Alexis: Excellent. Thank you. can you tell me about your key principles [00:01:00] and how they are essential to, to build an engineering 

    culture? 

    Bruce: Yeah, I have sort of this guiding leadership philosophy, right? I call it trusting team seeking excellence, driving customer delight. And so what I’m trying to kind of convey is sort of these three pillars for that. That every leader needs to balance, right? So how do you build a trusting team? How do you seek excellence and drive mastery? And how do you make sure you’re delivering customer value, right? And usually the challenges of engineering is keeping those in balance, right? And what I’ve learned over time as a leader is it’s all about the balance. You can’t get all of everything. You got to figure out how do you balance between these three?

    Because sometimes maybe like you would break trust with a team if you have to do something on the seeking excellence side. Right. And so how do you balance that and make sure that you’re doing it well. And so all of [00:02:00] my sort of sub values and things I think about is under that principle.

    Alexis: can you share your approach growing? A team of really starting something and, and help that team grow. 

    Bruce: Yeah. You know, it’s funny. Cause I was like trying to think, do I have a formula and you know, it’s, and it’s interesting because just so you know, I’m actually taking on a new team in a week. And so I’m switching roles

    and so I’m trying to think like, what do I do? Right. So this is, so I used to run a team called product platform systems. I’m sure by the time this releases, I will have the new job, which is a games platform and you know, it’s within Netflix, but it’s a totally different group. Right. And so I’ve been thinking about like, how do I, what do I do with this new team? Right? Like people know me but you know, not everyone right on the team. And so I think the first one I typically do with any team is. Set a vision first for [00:03:00] myself. So what what is this thing? I’m leading like what does this team do? What’s the essence their core, right? I think a lot of people think oh, this is the technology we build It’s like no no, but what’s the thing we’re driving at this goes back to the customer delight, right? Are we here for? Like our purpose, right? And 

    I actually wrote this memo for myself to figure out Why are we doing what we do? And in this particular team right in the games platform team, right and it’s a newer team You know, I don’t I don’t know if people know but netflix actually have games and that’s a growth area for us, you know over the next several years. And so it’s very Interesting. Kind of a little bit like a startup, right? And so I think for me, it starts with sort of that vision of what the team is and could be. And then from that, the next is who do you have? Who’s there? What are you building? Like, [00:04:00] what’s your team structure, right? The other anchor point you know, building trusting teams is really around the makeup and diversity of your team. Who do you have? Do you have the right parts? Do I have enough managers? Do I have enough ICs? Are they focused on the right areas? And so here’s the thing is like, if you think about a leader, how do you decide the right team structure if you don’t know where you’re going? Right. And so that’s why for me, it’s like know where you’re going and then figure out the team makeup. Right. And then the last part,

    I think this is the seeking excellence piece, which is, all right, what do we need to do now and do well, right. To deliver value. Right. And so it’s kind of like the vision, the team structure and our goals, right? What are we trying to do? And for me, I have a philosophy that I’ve written in my github page. And this is from a book called when now, when later, but winning now, winning later, which is like, you have to do tactical as strategic at the same time. Right. And so the goals that we have set is like, we have to deliver on 2024 goals. [00:05:00] We also have to prepare. For 25 and 26 and beyond. And so I think that that’s like kind of the, for me to get a team in a good place, you’re kind of building those sort of three things together. Now underneath all of that, you know, foundation to everything is trust. How do you build trust with the team? How do they trust you as a leader? Right? All this stuff does not work without trust, right? So that’s why trusting teams is so, is the first thing for me, is because, you know, I think you know this, if you don’t have a trusting team the vision is not going to make sense, they’re not going to trust you, right? The goals, they’re not going to push, and definitely hiring and conveying what the team structure is they’re not going to believe you. So I think that’s So, you know, like underneath that is constantly building trust with the team.

    Alexis: help me understand that. So I’m a, I’m one of the engineers on your team, hypothetically, not I don’t know. You, you, you are the new [00:06:00] of that team. Do you believe, I will trust you like 

    this. 

    Bruce: So in this particular, no, you won’t, I have to earn your trust. Now I do have a slight advantage in the sense that I have been here for four years, so I’m not some random person coming in from the outside, you already have seen. Multiple outputs of what I do and how I think at the company. And, and so the good thing is my reputation precedes me. I hope in a good way. I think people, you know, I have team members who actually used to work for me who actually advocated for me. Which is always nice to hear. Honestly, as a leader, like that’s the only criteria, do they actually want to work with you again? And so that comes with some level of credibility, right?

    So I’m not starting from scratch. But I’m doing actually something very early. I believe in vulnerability based trust, right? And so here’s what I’m doing. One is, you know, setting that vision doc early is to say, Hey, I want to learn more about the business, right? And I want to learn and [00:07:00] define a future that’s exciting for all of us to pursue. But the second is, The day I start, I have a town hall where it’s about me, right? Like, Hey, learn about me, read, read my leadership philosophy doc. You know, here’s my intro to me as a person, right? I live in San Francisco, you know, I have wife and kids, but, you know, like these are the things I like. I love food, right?

    I love travel, all that stuff. Right. And then something I’m doing is have the people who used to work for me, that’s on that team now giving. Verbalize critical feedback. They’ve given me in the past. What’s wrong with Bruce? Right? And you now as a leader, you have to be careful because coming in new vulnerability also has to be earned over time, right?

    If you just be like, I don’t know anything that’s not going to instill confidence, right? And so you kind of balance the like, I know what I’m doing, I think, but also I’m not perfect. You know, [00:08:00] I’m not infallible. I have, you know, I have weaknesses just like anyone else. So that’s how I’m doing it is right away. Try to build through that closeness of, Hey, I’m a person. And you know, I have flaws and then ask any questions and actually. I continue to encourage people, ask the spicier question the better, challenge me, question why I’m in this role, question what are we doing here push me hard, because what I’m trying to convey to the team is, I want the openness to discuss problems, I want us to be open about where our challenges are, you know, inside the memo that I wrote, actually I list out all the things I heard that is difficult for us as a team, And just wrote it out, like verbalized it and said, yeah, I know it’s really hard to be a startup in this giant company who’s been around for 25 years. Let’s not underestimate how hard that is, right? So that’s an example of [00:09:00] like, this is a difficult thing to do. And so that’s kind of like tactically what I’m doing as well is just introducing myself, but not not just, oh, here’s who I am, but like, kind of learn a little more deeply about me. 

    Alexis: I have to admit I loved I, I would love to hear the segments wrong about Bruce. There are people that know you. I love the idea. I need to do that. The, the other thing is when you said you write the memo about the vision. Why are we doing what we do? That means you’re not doing that in isolation.

    You’re, you are interviewing a lot of people probably the team and in the 

    Bruce: well, and that’s the thing is I wanted to be careful, right? Because when I originally wrote when I started writing the doc It was for me to like write down what I thought this team was doing and I’m like, I don’t know enough so instead the memo became more like embrace hard mode It went from, like, specific, tactical, here’s the technologies we need to work on, to, [00:10:00] we need to embrace the challenges ahead of us.

    So it became more of an inspirational, yeah I know it’s hard, but we’re going to have to do it. Because if we want to do, you know, I wrote something in the memo, I said, if we want to do extraordinary things, we need to overcome extraordinary obstacles. So. Anything worth doing is hard, right? Like, that’s just how things are. And so, the memo became more like, let’s embrace the hardness. Not overwork, but just like, yeah, it’s difficult. You know, you’re trying to build a new system, trying to establish product market fit, but you still need to integrate with Netflix. So how do you do it well? Right? That’s not an easy thing, right?

    You got systems built for SVOD, not for games. How do you integrate with those systems? And there’s real technical challenge of that. And so I sort of shifted from like, here’s what I know what we want to do to like, I know how hard it is to be in the situation. [00:11:00] And then look, I still need to collect a bunch of feedback and, and figure out, you know, what’s wrong with it.

    And, you know, I’m, I readily admit, like, look, I don’t know what should be in this doc. You know, I just kind of wrote. My initial version. But the, the good thing is, you know, the first few people I shared it with were like, Oh, this really resonates. So then I’m like, okay, I’m on the right track. Right. At least I didn’t write something and people were like, this makes no sense.

    Why did you write it? Right. And so I think that’s also how I work too, is that I think a leader will put out a vision memo and they think it’s like written in stone, dude, we can completely change this however we want. Right. And actually more information I have will help us make this memo and this. Vision better, right? So that’s kind of how I’m thinking about it. And so yeah, definitely inviting people you know being transparent of what you’re trying to do. I think is really important You know, you kind of want to show I don’t know. I’m kind of like a show and doer at the same time You know what?

    I mean? Like I you know, I don’t want you to just trust [00:12:00] me that I Am a trusting leader. I want to be transparent. I want to be open I want to be vulnerable like i’m just gonna like, you know Do it, not just say it. Right. And so I think that’s also important as well.

    Alexis: Excellent. And the next question is also about doing and saying or doing and helping others. It’s about growing people. And I know growing people starts often with oneself. So help me understand how you. What is your philosophy about growing people?

    Bruce: Yeah, I I think everything is about growth mindset, right? Which is just the idea is just because you don’t know something now doesn’t mean you can’t learn it. Like, right. The idea that you can get better and be better. Right. And so I think you said you start with yourself, right? You realize where your challenges are. You realize is where, where you, maybe your weaknesses are. And, and you, you want to like get better, [00:13:00] but the second thing about growing, which is also recognizing what you’re really good at, what you’re like exceptional at, right? Like what’s my superpower and how do I like do that more? Right. So I’ll give you an example. One of my superpowers is like connecting with people and networking within the company. And one of the challenges of games is that it’s sort of insulated and ice, you know, isolated. And so my job is using the connections I already have to start doing road shows, right? So that’s an example of like, how do I also use my own strengths to my own advantage, right?

    And so that’s for me. And then, then about to the team, that’s where it goes back to earlier. I mentioned figuring out what you have, where the strengths are, you know, what can you push, right? Where can you help support and coach where there’s weakness or, or, you know, somewhere to improve. And so I think.

    Growing people, I like what you said earlier is like, first it starts with yourself, right? [00:14:00] You have to be humble enough to know that, you know, you don’t know everything. And then I think when you work with people then you, you got to figure out as they. Build that trust, then they can open up to, here’s what I’m good at, here’s what I’m not, here’s where I want to grow. Now, also as a leader, the challenge is that, you know, I’ve had the benefit of leading ICs, but as I build up the team, I don’t directly lead ICs anymore, right? And usually I have managers who then lead ICs, so then how do you grow people when you’re not directly interacting? With the ICs, right? And so you have to grow your leaders, right?

    You got to grow your people leaders and make sure your people leaders are reflecting sort of the vision and the ideals and pushing you as well, right? Cause my, my people managers pushed me all the time to get me to think, rethink and learn. And so I think that’s the other thing is as you move up, it’s really about scaling yourself, right?

    You can’t meet everyone. You need to make sure you’re building [00:15:00] the scalable structures. So that the, your managers and their managers can like build strong teams. Right. So I think the growing also is about scaling out beyond just you personally, you know, one on one growing someone.

    Alexis: Yeah, love that and it’s funny because I’m starting working with a new customer this week. And I always love when I’m able to meet with everybody on the team. And during the first call before we started, he told me, Okay, so there’s 800 developers on the team. And I said, okay, so that will not happen. I will not meet with all of them.

    That’s for sure. So now we need to have a really good strategy to scale myself because I will not have 800 meetings during the first week. That, that not even during the first year, 

    Track 1: it will probably not 

    Alexis: happen. So, yeah, I am saying, and it’s, it’s really different to be directly managing the team of individual contributors.

    And [00:16:00] starting to have managers will do that with you. ,

    Bruce: By the way, that’s actually a really great tactical example of growing my team. If you look at my previous team, I, when I led Netflix, first team I led at Netflix was API systems, right. And it was just ICS, right. And the whole point was me coming in

    to help. Establish like a team structure, but it was all ICs. And actually that was a real growth area for me is when I started getting, you know, man, engineering managers, it was this weird, like I had, you know, worked with a team to build out this vision, but then now I have managers who’s. Pushing that vision and changing the vision. How do I let go right? And so growing the team sometimes is letting you letting go Like you not being in it with you know, like because you feel like I felt obligation.

    I felt like hey This is my you know, this is the team we built together I don’t want to let go and actually growing the team sometimes means letting [00:17:00] go

    Alexis: Oh, I feel that’s important. Letting go. Okay. We’ll put bold at some point. So can, can you share a challenging project that really, really stretched your skills?

    Bruce: Oh, man, they’re all challenging I mean When I first started, so I always tell my story of when I started Netflix because it was the hardest job I’ve ever done in my life, right? Times two, because here’s what happened first. I come into a dream company. Right where you you know, i’ve been following the culture for years I’ve designed my engineering culture based on the culture So you have an aura like I have no idea how it really is in the company I’m, just like oh my god They must know everything and they must be right on everything and they must be the best company everywhere, right? So you already have that first off you have deep imposter syndrome coming in then you have a memo that says

    Keeper test dream team [00:18:00] a players, right? So then you’re always constantly worried. Am I gonna get fired like at any point? Right to then you come in and, you know, I’ve been mostly startup founder and, you know, worked at startups leading teams.

    And this is a order is multiple orders of magnitude, higher traffic, you know, services much more complicated systems architecture, right? The technology is way harder than I’ve ever seen before. Right? So you got that. And it mixed all that together. COVID hits in March of 2020, right? So I start Jan of 2020, I get two months in the office and then it’s locked down. So you also are facing with an existential crisis within the world and Netflix. Cause Netflix was built to be a in person company, right? I still remember early on attending meetings with you know, we had this major API migration project, [00:19:00] right. Dot next to edge pass. So NEXT is this, you know, API platform that we built over many, many years, and EdgePass was kind of the new GraphQL like graph language API, and it’s been already going on for multiple years, right? And in the check in meeting, everyone was in the room. Right. Like literally all the engineers and I’ve never seen that before. I was like, Oh my gosh, everyone’s here. This is amazing. I’ve never, you know, like mostly work for startups where it’s all remote and distributed. It’s like everyone’s in the room and we’re talking about this project. And so you go and lock down everyone’s remote. So you’re also dealing with like the companies aren’t even prepared for that, right? Like, like we’ve never done that before. And so to me, that combination of just, do I know what I’m doing? Am I going to get fired at any time? Plus. You know learning an environment that like, you know, everyone was dealing with right?

    Not just us was just super super hard and I don’t know how I got through it Honestly you know [00:20:00] i’m like I tell people it took me Nine months to really understand nine months to a year to really understand what the team did right? And then took me really two years to feel comfortable. And so that journey Here’s what’s interesting.

    It’s not one difficult thing, right? It’s like 10 20 difficult things. And actually what was really hard about that situation was even after I built up, you know, good rapport, I actually fell down like a year and a half in where it’s like, Oh, I felt good. And then like I made a huge mistake with the team and lost some trust. Right. And so like, you have to then rebuild that and figure out, Oh my gosh, what did I do wrong here? And so the building out API team to be this more scalable team So the vision that I came up with was hourglass to turbine So hourglass is what everyone tells API is right? It’s in the middle layer between two huge [00:21:00] groups like UI and back end teams So, you know, we’re the middle layer that like a hourglass right that that That choke point. And we want to become more of a turbine or engine for innovation. So it took many, many years to figure out how to do this thing, right? This really complicated piece of the ecosystem and moving it to a more scalable architecture and team structure. And not everyone was happy about the move. Right. And so it that’s another

    example of trusting teams and seeking excellence conflict with each other. Right. And so, so this journey was really a multi year journey that had come with many difficult up and down. Right. And so it’s not a single event that I can say, Oh, that one thing was really hard. It was just like the whole journey. Was really hard. 

    Alexis: I love it. And the context was definitely how say, interesting or really challenging. When when I listened to what you said [00:22:00] about your, your leadership philosophy, I was wondering how the, how the system, how the, I understand the organization is really important, but I owe the system, the processes, the tools, are they, are they important in what you are doing or?

    Let me understand how you you deal with that.

    Bruce: Yeah. So when you say systems tools, do you mean like technical tools or do you mean like pro like JIRAs and Kanban boards? Like, I’m just kind of curious, how do you mean?

    Alexis: I I mean everything I I want to leave it as much open That’s up. That’s all the things you you know that there’s a deming We’re saying always that a bad system will beat each time The system is really everything That people will interact with. And so I’m, I’m curious about what is in the system you and what you feel you are to 

    Bruce: Right. So, so here’s, what’s really interesting about Netflix is that Netflix is well known for a culture [00:23:00] aspect called people over process. Right. And so actually, we’re like very shall we say, like, not anti process, but just like, oh, process is bad. And like, that’s actually a culture meme we have to break, right?

    Like, process is not bad. I mean, deploying code, CICD, that’s a process, right? Like, you know, running offsite is a process. Like, you need processes, right? Like, and so you can’t treat it as a dirty word. And so actually, the thing I had to fight was how do we introduce some lightweight processes? Right. Can we just use Jira’s to track what we’re working on? Right. Can we have like a lightweight Kanban board, you know, to just see what the team was working on. So what’s interesting is what I’ve learned over time is that everything you learn, all the tools you learn, you have to apply for the situation and the problem on the ground that time. So what I had built before of like building Kanban, for instance, I, you know, [00:24:00] built Kanban processes.

    And I, I, I’m kind of like. That’s kind of a strength of mine is when I read something about a process, I can kind of synthesize it pretty quickly and get to the core of why you do it, like OKRs or Kanban boards or whatever, right? And so those are easy for me to implement in a good way. Like Kanban is all about limited WIP, right?

    Work in progress. Right. And you’re trying to stop the line when you’re having a problem, right? It’s not about filling it with a billion things. It’s about actually filling it with less things and

    doing Right. And so those things I can do and so implementing some lightweight process when there was no process or very little, because at Netflix process was actually considered bad. Right. And so that was actually, the challenge is that you have to kind of take into account the team you have, the org structure and culture you have. And then figure out how to like integrate into that. I actually got feedback early on. It’s like You [00:25:00] know, I was trying a bunch of different things I read and they were like, Oh, my team was worried.

    Like, Oh my God, this is some like guy who read a bunch of blogs and I was trying everything. And, and, and it was funny because, you know, I was doing that. That’s what I was doing. I was like, Oh, I read, this is a good structure. Let me try that. And it’s like, I had to adapt, right. And what happened, what helped. What helped the team realize is, look, I’m a startup person. If something’s not working, I’ll just throw it away. I’ll try a different thing. Right. I’m not going to try to force feed some process down your throat until I make it work. Right. And so that was my process is like seeing what worked with the team. Trying, what were the things that resonated? Didn’t, you know, I try to put stuff in air table. That didn’t work. Okay. Throw it away. Do Kanban boards. Okay. That worked. Cause we’re mostly using JIRA. We were doing sprint planning and we’re switching over. And so that’s the example of just. adapting to who you have and the company you’re in and being able to implement some things to put more structure [00:26:00] to just organize you know, the team a little bit.

    And so I think for me, it’s not about a set thing, like implement these 10 things and it will work. Right. It’s about like, it’s kind of like that growth mindset mentality of like, what are we trying to do right now? And how do we make it better? So it’s more of a philosophy of how we get better. That’s seeking excellence. Making the system work better rather than a specific thing. So I’m more principle based on that than like a formula of things.

    Alexis: I love it. I, I would love more people to answer that question with a more base. I just think that way would be more probably interesting for them to, to realize that implementing a framework or adopting best practices is not necessarily the best option they can pick. That really are reflecting on the core principles is probably 

    more important to adjust and adapt.[00:27:00] 

    The current 

    Bruce: Yeah. I’ll get, I’ll give you a quick example here. Is whether we like it or not, I think Netflix has influenced the industry on like graph QL, right? Because my team, my team’s actually wrote blogs about sort of our federation technology and stuff like that. And I always find it very interesting when teams say, Oh, Netflix is doing it.

    So we must do it, but why Netflix has very specific reasons why they’re doing it. You know it, it’s not just. Like because we want to you know, and I think that’s also very important like where I find it people like want to copy success Right, like oh this company’s doing this. Let’s just copy what they’re doing without recognizing what they actually need.

    Alexis: Yeah. It’s a very, very dangerous do. It’s harder to really understand the core principles. So it can be off. Ah, that’s a, that’s good. You, you went from being an individual contributor to a [00:28:00] higher level leader in a, in a new large organization. And as you said, a dream company what, what is your perspective of what makes, what makes a good, a good people leader?

    Bruce: Man, that’s so so there’s, there’s a book I read called Team of Teams by General McChrystal.

    And he, he had one of the best lines. He said he looks at himself as a humble gardener. And it’s like one of my favorite images. Is like being a humble gardener, right? So one is being humble. Like don’t assume, you know, everything and the gardener piece is more about for me It’s the image of in the dirt with the team figure out what needs to be done clearing the brushes Making the environment in which everyone can grow right?

    So I like that mentality of like Your job as a leader is to make sure everyone else grows and gets better [00:29:00] and sometimes it depends on what the situation sometimes you have to take a much more hands on approach Right given the you know the current team Structure or current experience of the team and other times you just need to let go and let let it shine Right, and so it’s it’s very dynamic, right?

    It’s based on the situation so I think those those two things really speak to me like if I think about what kind of leader I want to be. It’s that it’s like that humble gardener approach of like being, you know, able to work closely with the team, but also knowing what you don’t know. Right. And honestly, I think comes down to just curiosity as a leader. Like, you have a lot of experience, right? Great, but maybe you don’t know everything, and that’s okay, and being okay with not knowing everything, and learning, and that drive and thirst for learning, and being better, like just being wanting to learn more and [00:30:00] get better, incorporate more concepts. Don’t think you know everything I think is just like a key attribute of any leader whether you’re a people leader.

    IC leader

    Alexis: Yeah, I love that. I love that. And a really good reference. I love that book. And I was about to say that there’s a, there’s a lot about curiosity, but you said it. That’s perfect. I will put the link the comments we are about to, to be at the end the episode.

    What is the question I should have asked you?

    Bruce: Well, that’s a good question. you kind of addressed it which I think you could have pushed more is the failure modes Right? Like you asked, like, Hey, what was the hardest thing? So I think that was good. But maybe even digging deeper on like, what were the failure modes and like, what did you learn from them? Because I feel like it’s not about the success that defines us as a leader. It’s about how we dealt with the failures that defines us. And so I think if [00:31:00] like, maybe it’s more like drilling down into where are some of those points that you learn from a failure or some situation like, you know, I mentioned to you like I had a problem with the team that I thought I lost some trust.

    I had another one letting go right to my managers. I think those are always the, what I don’t like about the world of, you know, whatever you want to call influencing leadership, you know, talks is it’s, it paints too rosy of a picture sometimes, right. You’re, and you’re actually seeing a lot more practical discussions of like, what’s hard about leadership, not what’s easy everyone could talk about being a leader, but it’s actually pretty hard to actually be one.

    Right. And so I think that would probably be, you know, a good question is to drill down in some of the failures more deeply

    Alexis: do you want to, try the for us? 

    Bruce: Sure, sure, sure. Many. I can’t, I can’t even pick all the mistakes I made. Let, let, let’s [00:32:00] pick the failure mode where I think this one is important because this is where I had built some confidence with the team. So this is when I lost some trust with the team. I had already built some confidence on like knowing what I was doing. And that’s actually, it’s funny because that’s kind of where hubris kicks in, right, where as a leader, you’re not being humble anymore, and you’re sort of like, Oh, I know what I’m doing. I’m just gonna push forward. And so the situation was that we had a new VP and we want to present our strategy for Consumer Edge, right?

    So Consumer Edge was our new federated GraphQL API for the consumer product. We already established it for our internal enterprise within the studio applications. But we want to move towards consumer, which is the Netflix app, right? The product itself. And so I spent time with one IC who is a big proponent of that vision, right?

    And we wrote the vision doc together and it was great. And I actually even said, let’s write it without even using the word GraphQL in it. [00:33:00] Because what are we trying to do, right? The vision is unified API, democratized edge, right? So what that means is you unify all the APIs together. Because, you know, before we used to have like per UI based APIs. With BFS or backends for frontends. And we want to unify on a single GraphQL API, but then democratize in the way that it’s unified. But the people that own it are actually the domain owners, right? So the identity graph is owned by the identity team. Not managed by an API team. So really excited. And we presented to the VP and, you know, I think it went okay.

    And it was fine, but my team was like, what are you doing? Like, why are you talking about this? Like, we’re not even sure if this is going to work. And it was like, like multiple senior engineers in the team really pushed back on the concept. It’s like, we don’t even know if this thing will work. And why are you talking about this thing?

    And, [00:34:00] you know, what are you trying to do? Like, it was almost like, are you trying to like dismantle the team on this new vision? Right. And I was like, whoa, what, you know, because of my push for speed and push for like, Hey, I want to get this in front of this leader. Who’s new. I actually didn’t take the time, right.

    I used. My confidence hurt me here, right? I thought I built the trust of the team. I pushed fast and I didn’t collect enough information. And so when I presented it, it wasn’t a cohesive vision that the whole team supported, right? And then I had to go back and

    really work with you know, the more senior leaders to define a more cohe I mean, I remember, I even remember us, cause it was lockdown, and we had to like find a room outside to like meet the four of us, right? To just like talk through the vision and be like, okay, what is really underneath this? What’s the meat of it? How do we really make it happen? [00:35:00] Not just write a doc. Right. And I still remember sitting with the four of us like outside discussing, you know, in person, cause you know, it was also remote. Right.

    So that didn’t help. And we were like social distancing and trying to discuss this vision together. So that was, that was a key moment for me because I felt really bad and the team was just like, you know, we’re like, I’m really disappointed. You know, I was like, Oh my gosh, how did I mess up this bad? 

    Alexis: thank you for sharing because it’s, it’s very interesting and it shows the other face of that. spoke about the humility that is needed and I love the way you presented the vision doc and the fact that it was really a collaborative document that you refine each time you meet with someone.

    And then, yeah, you’re confident in that vision and you want to take a shortcut and Boom, doesn’t work. And it’s very interesting. Each time you, each time we take a shortcut, [00:36:00] should think a little bit about, is it worthwhile? Is it really a shortcut?

    Bruce: yeah,

    Alexis: And yeah, 

    Bruce: yeah, yeah, no, that’s a great one. Yeah, I liked that term. Is it a shortcut you took? And absolutely it was a shortcut because it was speed, right? Like I wanted to go fast and like present quickly. Right. 

    Alexis: Thank you very much, Bruce. Thank you for, for joining me on the podcast today. I really appreciate 

    Bruce: No, it was great. It was really fun. Yeah. We’ll do it again.

  • Leadership: A Contested Term

    Leadership: A Contested Term

    Leadership is a contested term.

    The Merriam Webster defines it as:

    • the office or position of a leader,
    • the capacity to lead,
    • the act of leading,
    • the leaders.

    Leadership is about influencing others towards achieving common goals. Understanding leadership is akin to exploring a vast and diverse landscape, where each theory and style offers unique insights into how we can inspire, guide, and evolve with our teams.

    The Multifaceted Nature of Leadership

    The concept of leadership has been dissected and redefined through various lenses. Leadership styles range from autocratic, where decisions are made singularly at the top, to democratic, which involves team input and consensus. Then there’s transformational leadership, which seeks to inspire and motivate, creating significant change in individuals and the organization’s culture.

    Emerging Leadership: A New Paradigm

    As our understanding of leadership continues to evolve, a new paradigm has emerged: Emerging Leadership. This concept challenges the traditional hierarchy and fixed roles, advocating for a dynamic, adaptable approach to leading. Emerging leadership is not confined to designated leadership positions but is an attribute that can manifest across all levels of an organization.

    This form of leadership emphasizes emotional intelligence, adaptability, and the capacity to foster innovation and collaboration. It’s about creating an environment where leadership is a shared journey, encouraging individuals to step forward and lead in moments that call for their unique skills and perspectives.

    The Benefits of Emerging Leadership

    Emerging Leadership offers numerous benefits to organizations, including enhanced agility, a more engaged workforce, and the capacity to innovate continuously. By recognizing that leadership can come from anywhere within the organization, we unlock a powerful source of energy, ideas, and motivation. It leads to a more resilient organization capable of adapting to change and seizing opportunities in today’s fast-paced world.

    A Call to Embrace Emerging Leadership

    The call for Emerging Leadership has never been louder. It’s an invitation to rethink our approaches to leadership, recognize the potential in every team member, and build environments where innovation, collaboration, and adaptability are encouraged and embedded in our organizations’ very fabric.

    Through my upcoming book on Emerging Leadership, I aim to delve deeper into this transformative approach, offering insights and practical strategies for leaders and organizations ready to embrace this change. Leadership is not a static concept but a dynamic and evolving journey. By adopting the principles of Emerging Leadership, we can ensure that this journey is as impactful and fulfilling as possible.

    If you’re intrigued by the potential of Emerging Leadership and eager to explore how it can transform your approach to leadership, I invite you to subscribe to the newsletter. You’ll stay informed about the progress of my upcoming book on Emerging Leadership and learn how you can engage in the writing process. Your insights, experiences, and perspectives can enrich our collective understanding and application of these principles. Together, we can shape a future where leadership is more dynamic, inclusive, and impactful.

    Join the Newsletter

    Join us on this journey of leadership development. Subscribe to our newsletter today and start unlocking your leadership potential.

      We won’t send you spam. Unsubscribe at any time.
      Built with ConvertKit
    • Revisiting ‘Good Strategy Bad Strategy’

      Revisiting ‘Good Strategy Bad Strategy’

      In my latest reading journey, I revisited a cornerstone of strategic thinking, “Good Strategy Bad Strategy” by Richard Rumelt. This masterpiece, which I’ve always held in high regard for its insightful analysis and practical advice, struck a new chord with me, illuminating facets of strategy with even greater clarity. My return to Rumelt’s wisdom was serendipitously timed with Lenny Rachitsky‘s latest podcast episode, where he engages in a thought-provoking conversation with Rumelt himself, diving deep into what makes a strategy truly effective. I highly recommend listening to this enriching discussion, which is available here.

      The Essence of Good Strategy

      Rumelt’s delineation of a good strategy as a coherent blend of policies, actions, and resources uniquely designed to tackle fundamental challenges is more relevant today than ever. The “kernel” of a good strategy, composed of diagnosis, guiding policy, and coherent actions, is a robust framework for leaders at all levels. Reflecting on my experiences, I’ve not witnessed often the transformative power of a well-crafted strategy. It’s not merely about the resources at one’s disposal but how effectively they are aligned and mobilized to overcome obstacles and seize opportunities.

      The Pitfalls of Bad Strategy

      Rumelt’s identification of bad strategy through its hallmarks – fluff, failure to face the challenge, mistaking goals for strategy, and bad strategic objectives – offers a critical lens for evaluating our strategic approaches. As a leadership coach and organizational consultant, I’ve encountered these pitfalls and worked alongside teams to avoid them, emphasizing the importance of clarity, realism, and actionable objectives. Regrettably, I have experienced organizations stumbling into some, if not all, of these pitfalls firsthand.

      “Good Strategy Bad Strategy” remains a seminal work for anyone serious about understanding and applying strategic principles in today’s dynamic world. My recent rereading, coupled with the enlightening conversation between Rumelt and Lenny, has reinforced my conviction in the power of strategic thinking to shape successful, resilient organizations and leaders. As we navigate the complexities of leadership and organizational growth, let us lean on these insights to craft strategies that are not only effective but truly transformative.

    • Redefining Growth: Pearlside’s Vision Beyond Numbers

      Redefining Growth: Pearlside’s Vision Beyond Numbers

      To redefine leadership and organizational growth, looking beyond conventional metrics is essential. Recently, while discussing Pearlside‘s value proposition, I encountered a thought-provoking question regarding our milestones for growth at different scales – 50, 500, and 5,000 people. This moment of surprise sparked a deeper reflection on my true aspirations for growth and impact, leading me to share insights inspired by the renowned design firm Pentagram.

      A Vision Beyond Numbers

      Pentagram represents a collective of world-class designers, each a leader in their field, united by a desire for greater opportunities, learning, and impact. This model, far from focusing on arbitrary numerical milestones, emphasizes collaboration, innovation, and nurturing a network of excellence.

      At Pearlside, we are not chasing the numbers. We aim to assemble partners passionate about enhancing leadership and management skills across various levels and sectors. We envision a community where partners can thrive, learn from one another, and collectively contribute to a broader impact. Whether choosing to work independently, collaborate, or lead specialized offices worldwide, the essence of our growth is qualitative, not quantitative.

      Learning from the Best

      The Pentagram model teaches us the value of surrounding ourselves with top-tier talent. We elevate our collective expertise by fostering an environment where partners can exchange feedback and learn from each other. This approach aligns with the belief that you are the average of the company you keep, pushing each member of our network to strive for excellence and, in turn, amplify our collective impact.

      Flexible Paths to Impact

      Our vision of growth is flexible and adaptable, acknowledging that the path to impact varies for each partner. Some may prefer to work alone, others in collaboration within or outside Pearlside, and yet others might wish to establish specialized offices focusing on specific markets or regions. This flexibility ensures that our approach remains inclusive and broad-minded, catering to our community’s diverse needs and aspirations.

      An Invitation to Reflect

      I invite you to join this conversation, sharing your insights and experiences on redefining growth beyond the conventional metrics. Let’s explore together how we can shape the future of leadership and organizational development in a way that prioritizes meaningful impact over numbers. Please use the comments on the YouTube video or the LinkedIn post.

    • Outcome-Based Leadership Without the Bureaucracy

      Outcome-Based Leadership Without the Bureaucracy

      Outcome-based leadership is everywhere in theory. In practice, it often collapses into two familiar traps: goals become tasks, or goals become top-down control.

      In this episode, I spoke with Tim Beattie and Bella Bardswell, co-founders of Stellafai, about what it actually takes to build an outcome-focused culture that improves collaboration, increases autonomy, and keeps teams aligned without crushing initiative.

      Their perspective is shaped by decades of experience in consulting and transformation, and by the reality of building a product company from scratch.

      When OKRs trigger people, it is usually not about OKRs

      One of the most practical parts of our conversation is how Tim and Bella handle the strong reactions people have to OKRs.

      Many leaders say they “hate OKRs” because what they experienced looked more like classic management-by-objectives:

      • top-down cascading goals
      • pass-fail grading
      • goal setting as performance management
      • little room for experimentation
      • metrics used as pressure rather than learning

      Tim and Bella’s answer is not to defend a framework. It is to bring the conversation back to first principles:

      • clarity on the outcome we want
      • evidence that tells us whether we are getting there
      • experiments that help us learn what works
      • a shared rhythm that keeps outcomes alive

      And if the term OKR is a blocker, they change the language while preserving the mindset. Same approach, different words. Goals instead of objectives. Measures instead of key results. Experiments instead of tasks.

      Collaboration first, frameworks second

      Tim’s core message is simple: collaboration is the foundation.

      Before metrics, tooling, or structure, leaders need to create the conditions for real conversations:

      • between technical and business people
      • between teams that depend on each other
      • between leaders and the people closest to the work

      Getting people in a room, visualizing the work, and arguing about the words is not a distraction. It is the work. That is how shared understanding forms.

      This is also why tools like impact mapping can be powerful. Not because the artifact is magic, but because the mapping forces the conversation: actors, behaviors, impacts, and outcomes.

      The hidden cost of growth

      We also touch a pattern many leaders ignore: communication complexity rises sharply as teams grow.

      Add just a couple of people, split across rooms or locations, and suddenly alignment disappears. Nothing “important” changed, except everything did. Teams need systems that scale clarity and coordination, not just more meetings.

      This is where outcome rituals can help. Not big yearly launches. Not glossy presentations. Small, recurring check-ins where teams look at the measures and ask:

      • are we on track?
      • what do we change?
      • what should we stop?

      Over time, this becomes a way of working rather than a process.

      AI as a team member, not a replacement

      Stellafai’s use of AI is deliberately framed as supportive.

      Their aim is not to replace coaching or human interaction. It is to add an “extra team member” that helps teams start thinking:

      • suggesting measurement ideas
      • proposing experiments
      • nudging teams toward better options
      • reducing admin so time goes to the conversation that matters

      The value is in acceleration and better prompts, not in outsourcing leadership.

      Inclusion as a built-in practice

      Tim and Bella also share a clear stance: you cannot retrofit inclusion later.

      They treat diversity and inclusion as something you build into your values, your hiring, and your daily practices. Simple facilitation patterns (structured turn-taking, visible participation, safe ways to contribute) matter because they give people a real voice. Inclusion is not a statement. It is a set of habits.

      Advice for emerging leaders

      Their closing advice lands in three moves:

      • Collaborate: create the conditions for real conversations
      • Prioritize outcomes: narrow the focus and make it measurable
      • Make it enjoyable: leadership is a long game, build a culture that people want to be part of

      References

      Transcript:

      Alexis: [00:00:00] Welcome to Le Podcast on Emerging Leadership. I’m your host, Alexis Monville. Today, we are thrilled to have Tim Beattie and Bella Bardswell, the co founders of Stellafai, a company pioneering in outcome focused approaches to team collaboration and leadership in the tech industry. 

      Tim, with his deep expertise in agile and lean methodologies, and Bella, known for her transformative work in cultural change, bring a unique perspective to the table. We’ll explore their journey in co founding Stellafai. The challenges and triumphs of emerging leadership and their innovative strategies in the tech world. 

      Welcome to the podcast on emerging leadership. Could you each share a bit about yourself and what led you to cofound Stellafai? Maybe Tim you want to start?

      Tim: Yeah, sure. 

      Thanks Alexis. Thank you for having us on your podcast. My name’s Tim Beatty. I. Spent the majority of my career working in [00:01:00] consulting large consulting organizations including PWC, IBM, Deloitte a couple of smaller boutique consulting organizations.

      So I’ve always worked in the world of services and delivering professional services to clients. Most recently I worked for Red Hat where I met you, Alexis. And I was responsible for a part of Red Hat called Open Innovation Labs. Open Innovation Labs was a slightly different services model in that the focus was all around enablement.

      It was all about enabling customer teams to get the very best out of, in this case, red Hat technology. the focus on on successful enablement. It was all about ways of working, all about culture. Practices mindset a little bit about the technology, but you know, to technology is sometimes the easier part.

      It’s more about the ways of working around the technology. my time at Red Hat was very re rewarding. I loved learning more about open source and open organizations and it felt like a really good blend [00:02:00] to the work that I love, which, and I’m passionate about, which is all about business agility and lean and agile and, and frameworks like that. so I spent five years really switching away from being a delivery consultant into an enablement consultant. And that really I found very rewarding. I, I look back on the teams that I helped kickstart the organizations that I helped transform.

      And once I got a bite for that, that that felt like that’s, this is, this is the kind of world I want to, to, to live in. This is the kind of career I want to continue. So I co-founded Stellafai with Bella a little under two years ago. And again, that was building upon this idea of enablement. It was about how can we help organizations really achieve their outcomes, their measurable outcomes.

      And we’ve done that. We’ve, we, we had some great ideas when we, when we paired up on this of, of some software that could help with that of an alternative model to to [00:03:00] coaching in a more asynchronous, contextual way. And, and we wanted to leverage the, the work that we’d done in our previous 20 to 25 years.

      So we brought all of that together to form Stellafai. And I think we’ve come up with something really exciting and I, I love being a part of it.

      Alexis: Excellent. Thank you Tim. And I still remember the, the first time I really met you in person. That was, I believe at A gile New England, in Boston. And, see you showcase what was happening in an open innovation labs residencies. You showcased in a one hour long session what was happening in a whole week of engagement and even more than a week. So that there, that was very, a lot really a lot of fun. But before I, I recall my memories.

      Maybe Bella, you want to, to say a few words about yourself.

      Bella: Yes. So my, my background on, on a quick glance looks quite similar to Tim, but we’re actually, we’ve had very different, different experiences, which I think is why our partnership works so well. We were able to bring that together with the. Enough common [00:04:00] ground that took us in the sort of shared direction and vision.

      So I, most of my career was in IBM big, big digital transformation programs, and I’ve done most roles along that journey. So business analysis, business architecture, change management, business change program management, then the sort of leadership and sales sort of elements. But the sort of thread that’s gone through all of that is I did a lot, a lot of work in government and the thing that I didn’t realize at the time that made me love that so much is that real clarity over why it mattered.

      You could always, you were building software, but you knew why. What it, what the reason you were doing that for. And it was really tangible and it mattered and that was. Really, really motivating. And then I started, while I was at IBM, I became familiar with Agile and that amplifies that, you know, what’s the value of what you’re doing?

      What’s the why? But I often found that people were kind of somehow managing not to do that. And then I, I went from IBM to Google. And at Google, many people know [00:05:00] they’re really, really into this framework, OKRs objectives and key results. And that’s really about having a very, very clear why and then a way of measuring if you’re getting there.

      And there are lots of different goal setting methodologies and they all talk about. Measurement, but very, very often no one does it. And they don’t really, they, their goal’s actually a task. And, and I started to, you know, realize I’d built up these skills and these insights, but all I could ever do was help the client I was with.

      And I, I was really inspired what Tim was doing at, at Red Hat with the open innovation labs. And when we talked about it, the idea of using software to be able to. Scale us and our experience and what models could we use? Like Tim mentioned, the asynchronous model, but also bringing in AI and, and just generally technology making less admin and more visibility easier.

      I was thinking this is a way that we could start to scale ourselves and, and help profoundly more people. So that was, that was really the vision, help helping. [00:06:00] Get the power of the why, but also using tech to, and different, different ways of thinking to help many more people get the benefit of that way of working.

       The brilliance of understanding why you are there and why what you’re doing matters. And then also if you track things, you’re more likely to get there. So then the, the real buzz of actually achieving what you set out to is something that we wanted to help more people do. Yeah.

      Alexis: Yeah. I really love it because then it it give us a, a sense of why you are doing it and not really how you are doing it. There’s some mystery about that, that I, I really like it. And of course on the podcast, I had the pleasure to welcome a lot of different people, and some of them talk about OKR.

      There was Christina Wodtke w ho is the author of Radical Focus, for example or Gojko Adzic , who wrote impact mapping. And we had a discussion about OKRs. And that’s because of him that, I had a short video on OKR, on impact mapping because[00:07:00] we discussed it. We discussed impact mapping and I explained to goco, ah, that’s how I’m, I’m defining OKRs.

      And he looked at me to say, no. Explained that to me. ’cause I don’t understand what you say. I said, you are the author of Impact Mapping. You inspire me to do that. And he said, no, no. Explain that to me. And I explained it to him. Say, can you, can you record a short video? I would like to share that with my partner because we never thought of it this way.

      And for me it was so obvious that, that, that was really funny to, to connect the two.

      Bella: Yeah.

      Alexis: One of the guests, I welcome the podcast. I, I prompt her to speak about OKRs because I was all excited about it. And my surprise was she was very against OKRs on the approach of OKR. And that person is Radhika Dutt, she’s the author of the book Radical Product Thinking. A book I really like. When she spoke about OKRs, she said, oh, it’s setting big lofty goals. It’s not collaborative enough. It’s more [00:08:00] like an end of year exam that you pass or fail. And you don’t even test if the strategy really works. And I was listening to that and say, no, no. So, but tell me what you think about that.

      What, what would you answer to Radhika about OKRs?

      Bella: Something that Tim and I and, and this, we get this a lot, so OKRs, just like Scrum actually, we’ve noticed a lot of parallels. You get a big framework, someone writes a book like Measure what Matters or Radical Focus with Christina Watt, and suddenly you get the lovers and the haters. You know, it feels like you have to pick a side, but actually I think all these frameworks have.

      Elements that are valuable, and then elements that you have to like go, that’s not gonna work in our culture for where we’re at. Let’s think about what will work. And one of the, one of the patterns we’ve seen come up a lot with OKRs is people, people’s perception of OKRs is actually much more like what happened in the sixties.

      With management by objectives, which was Peter Drucker and then Andy Grove adapted them [00:09:00] to OKRs. But a lot of people go back to the principles of MBOs and management by objectives. So that means your managers tell you what your goals are. They’re very, the word cascade is used a lot. Top down your, you give them.

      You have to achieve a hundred percent and it’s linked to comp, and that has all sorts of unintended consequences. If you’re not involved in figuring out what you’re going to do, you’re not committed. You’re not engaged. You don’t have a say. You’re not getting the opportunity to help people. If you said a hundred percent.

      Goal, it creates pressure. There’s no space for experimentation. it’s stressful. And if you link it directly to compensation, you immediately eliminate the desire for anybody to collaborate or to do anything, but just to try and focus on what they need to do to get paid. that’s extremely damaging to culture.

      All of those things are the exact opposite thing that you want to have if you wanna build great products. So. I think OKRs are often done that way. You know, someone reads a book, a manager reads a book goes, right, okay, it’s gonna take too long to do lots of collaborative workshops. So I’m just [00:10:00] gonna, for the first time, just write them and give them to them.

      And then I’m not gonna think about how we’ll embed this idea of thinking and. Around outcomes into my organization. We’re not gonna use this as a way to communicate understanding and to track progress and to decide what we should do. We’re just gonna shove it in step back and expect everyone to deliver the goals.

      And yeah, that doesn’t work. So elements of that happen in, or pretty much all the implementations Tim and I have, have seen in the work we’ve done, and you don’t have to use OKRs, you can just take this concept of setting a goal. Being clear about the outcome you’re trying to achieve and then figuring out how you’re gonna measure whether you’re getting there.

      Coming back to impact mapping, which is why it’s so great a way to measure the impact of what you’re doing rather than just ticking off tasks, which may or may not help you get there. So I’ve drunk the Kool-Aid, I think done well. They’re brilliant, but they’re often not done well.

      And often people put a lot of effort up, up front and then we call it set and forget, and then they never go back to it. They don’t think about how to [00:11:00] build it into how they operate, but it’s as much as a way of working and a culture and a mindset as it is a, a framework. I mean, the framework’s pretty skinny,

      a lot of people that have negative feelings towards OKRs based on experiences they have are entirely justified. But often I think it’s what still worth taking a look and, and exploring what happened in the past and whether it could, some tweaks could be made where you could get this really incredible power of everyone understanding what you’re trying to do, caring about it, being focused, aligned, and then tracking progress together.

       When done well, it’s, it’s phenomenal. 

      Tim: Your experience Alexis with, with that lady reminded me of something that happened. Probably about a year ago I was doing some beta testing of the platform we built, and I had some time with a CTO and the CTO looked at it and he said, Tim, I can never show this to my CEO because he hates OKRs.

      He got burnt by them badly, tried them in a previous company and he’s just an anti OKR. [00:12:00] Your platform set has got objectives and key results. We tried a little experiment we built a little feature, only took a, a day or two to build where we could customize just for on a per user basis some of the terminology and the naming.

      And for his space alone, we changed it so that instead of creating objectives, he was creating goals. And instead of creating key results, he was creating measures. And instead of adding the activities or the tasks he was writing about experiments. So I showed him and he goes, oh, my CEO’s gonna love this, the goals, experiments, and measures.

      He’ll really get that. Now. The interesting thing was our mindset, what’s under the hood, haven’t changed. We were still thinking about what is the problem we are trying to solve? What is the opportunity we’re trying to grab? What are the pain points and how can we articulate that in a really well aligned and shared view, you know, and not our goal statement or objective statement, a smart goal.

      There’s lots of different ways you could do it, but in essence, [00:13:00] that’s what we were trying to do. Then we were trying to come up with a series of qualitative measures, so needles that we could see move that were going to tell us if we were making progress or not. And we were going to encourage the idea of trying different things out.

      Designing experiments to see if the needle would move or not. So whether we call them, you know, to me we were still doing OKRs, right? But I could hear that there was a negative perception to OKRs, and it’s a little bit of consulting 1 0 1 here,, when you go out and you consult with a client.

       You’ve got to meet them on the language that they’re comfortable about. And if there is language , which is triggering some real negative emotion, it’s okay to change that. What’s not okay is to change the mindset that we know is going to promote success and deliver success. So it’s a very interesting, and, and just as Bella says, we’ve seen it with many things over the years.

      With Agile, with DevOps, with design thinking, with lean, and I think, okay, anything that goes [00:14:00] mainstream starts to get that Marmite love-hate relationship, and therefore we tread carefully with what’s the best way to introduce that under change management to organizations.

      Alexis: That’s a very good point. So the language can influence the perception. We can change the language, but maintain the culture or the mindset that we want to have about the collaborative aspect of it. You both mentioned that. Top down effect of I’m setting goals.

      Not saying we, we will forget about them, but if it’s not integrated in our way of working, we’ll definitely forget. What do you want to say about that collaborative aspect? And finally there , you worked in Agile and lean, you have extensive experience on those topics.

      So I’m interested in how we can get people to be more autonomous, more independent, more able to take matters in their own hands, or basically make leadership to emerge in the organization. So I’m, I’m interested in what you have to say about, about that collaborative aspect.[00:15:00] 

      Tim: For, for me, this is all about collaboration. Collaboration is the number one focus. Whenever I’m doing coaching, what am I trying to do? I’m trying to get people to talk to each other. I’m trying to get technical people to collaborate with other technical people. I’m trying to get business people to collaborate with technical people.

      I’m trying to get users to collaborate and I’m trying to get shared understanding and alignment for me. The best way to achieve the best collaboration is in a room. It, it is bringing the energy, the physical energy together, the room, the walls, the sticky notes, the visualization. I feel it sets us up.

      It gives us the best chance for success. So to kickstart collaboration, getting people physically together. And reaching a point where everybody has really got that feeling of yes, that’s what we’re trying, that’s why we’re here. [00:16:00] That’s what we’re focusing on. That’s what we’re trying, that’s what we’re trying to achieve.

      And almost with our arms around each other, feeling passionate about that. So I think there’s, there’s a lot of excellent practices that, that really facilitate collaboration, facilitate conversation. You, you mentioned impact mapping. That’s why I love. Creating OKRs through impact mapping because just the act of putting up those, just, just the act of getting people to, to write a goal statement and align on it and argue about it, and challenge about it and change.

      Swap one word out for another word. That’s all. Collaboration and it’s achieving shared understanding and alignment, agreeing the actors and. What, what do we call those people? What do, what do we call our users? What, there’s lots of different types of users that conversation. It’s collaboration, the measurable impacts, and actually what we’re doing there, we are building OKRs.

      We don’t realize we’re doing it, but we are a we are coming up with a, an aligned goal and we’re coming up with [00:17:00] a well thought out, measurable impact that we’re trying to help to get us towards that goal. But we’re doing it through conversation and visualization and energy. To me starting these in, in the room is, is just such a key foundational ingredient.

      And then I think that it’s how do we maintain,, how do we not lose that? And I think that’s that’s where, the emerging leadership, you talk about Alexis, 

      it’s a very much a diverge, converge. Can we go away separately? Autonomously, can we come back at regular points to synchronize and, and bring that challenge back together?

      Can we provide, can we get access to the support, the right level of support where it isn’t someone doing the work for you, but enabling you and just challenging you to think. So I think it’s putting that environment in place, that’s what promotes that kind of. Continuous improvement and evolving leadership so that there is a self, self controlling, self-management [00:18:00] aspect to all of these things.

       I personally think that the most important thing that goals does is enable conversations and that is communication. I’ve just got so many stories and everyone I speak to sort of nods sort of slightly sort of, oh, wly when I, when I say this, but we’ve all been to those like start of the year kickoffs where all the leadership spent weeks, months figuring out strategy. And then there’s this big launch of your strategy and there’s glossy presentations and oh, this is gonna make such a huge difference to the set of the company and la, la la, and it’s all nice. Maybe there’s some wine if you are lucky enough to work to that kind of company.

      Bella: And then after you leave there, it’s very nice seeing everyone. You go back and you just carry on doing exactly what you were doing before. So that is an example of a strategy, which is not going to be executed anytime soon, perhaps ever. That’s crappy communications. Like it’s the message received and the action that’s taken off the back of it, not the one delivered.

       And I think it’s not just OKRs and Tim just [00:19:00] touched on lots of things. We’ve got to get better at finding ways for, for people actually to receive the message well enough that they can understand and apply it to the work they do. Strategy execution is a huge challenge for all leaders and every leader should be worried about that.

      Writing some really, really crisp, clear goals that break that down and can then be decomposed through the organization. All aligning can give you a pathway right down to every single person on every keyboard working in alignment to achieve the goal. And if they then every week have a little conversation about how are they doing against their goals, that keeps that goal front of mind, that present big presentation disappears quickly from your mind.

      If you are looking at the the measures every week, that’s keeping it front of mind and then you have a conversation like, we’re on track. Brilliant. What was going well? Or We’re not on track, what do we need to change up? And you are. To your point, you know, you are empowering people. You know what you need to do.

      I trust you. Go do it. Let me know if you [00:20:00] need me to unblock it, unblock something or, or help you. And I think that’s incredibly powerful. But the other thing you’re empowering people to do is to say, this has nothing to do with what we’re trying to achieve. I understand what we’re trying to achieve. I think we should maybe talk about whether we should stop that and the amount of waste of pet projects and work, which has drifted from the mission and no one realized ’cause the comms weren’t there, is huge.

      So that I think that empowerment and communication I. Combination that you mentioned in, in your question can make a huge, huge difference to, first of all, business success, but perhaps more importantly, all of our ability to feel connected to purpose and actually do something, actually deliver something that matters, which I think is super, super powerful.

      Alexis: Focus on outcomes. I saw that a lot in your communication. There’s also that thing about AI and I’m a bit curious about that because we spoke about communication between people empowering people getting people in the room getting them really aligned, really get to that [00:21:00] shared understanding what, what AI has to do with that.

      Tim: Let me tell you the story about why we put AI in, in the end of our company name. So we were drawn to the word stellify, S-T-E-L-L-I-F-Y, which means turn into a star or or place amongst the stars. There was a lot of thought behind that because we thought about outcomes in organizations are connected and particularly measurable outcomes.

      This idea of, if you’ve got, say, a platform engineering team working towards measurable outcomes, they’ve got these little needles, which should start to move and if they are moving it’s connected to maybe some product teams and their needles can start to move quicker because of that connection. And if that’s successful, then it’s helping a business line and it’s helping them achieve their measurable outcomes.

      And that’s helping the strategy. So we are, we’re joining the dots. We’re forming this kind of idea of a constellation of stars where, you know, there’s [00:22:00] lines and what we want is really bright stars really bright constellation lines because of those connected outcomes. And we want to be able to zoom into those stars and understand what the energy is.

      So we were really taken by this metaphor. And it goes many levels deeper than that as well. But when we looked into trademarks and domain names, of course it, you know, the guy who had stellify.com wanted a hundred grand for it or something like that. So we did what every startup did, and we invented a word.

       We liked Stellar ’cause Stella’s, you know, we want everyone to be stellar and our people to be stellar and our customers to be stellar. We still liked that stellify and then ai, we thought, well, AI’s coming and I’m sure AI will filter into our company at some point. We, we actually didn’t plan for it at the beginning, but we thought, well, that, let’s put it in and we landed on, on it.

      Then of course about a year ago, the world went AI mad and everybody was doing chatGPT and Bart and open ai. And so we invested a sprint one [00:23:00] week. I can remember it well, November before last. One of our guys basically just did a little bit of a, a spike, bit of a prototype just to see , how could this AI help us.

       It’s a great question because we have some strong beliefs. We don’t want the AI to replace coaches. We don’t want the AI to replace conversation, collaboration. What we want the AI to do is to help that. So we’d liken the, our ai, which we call Armstrong, named after Neil Armstrong.

      We’d like an Armstrong to be like the extra team member. Think about the team members who’s just always great at throwing out ideas. Suggestions, just gets people talking just by, just by getting you started. When you’re drawing a blank and you can’t think, oh, let’s get some ideas. And there’s always that one person who’s just really good at getting the troops talking and throwing some ideas out on the wall, and then everybody starts talking.

      That’s what AI can do. So we’ve built things like Hey, Armstrong, can you, can you suggest some ways to measure, provide measurements against this [00:24:00] goal or key results against the objective? And Armstrong won’t do that for you, but it’ll get you going. It’ll just throw out 10 ideas and people are, oh, okay.

      Oh, that’s what a key result is. Oh, let’s tick those two and now let’s talk about those and let’s dive deeper or. Hey Armstrong. We’ve got this key result, but are there some open practices that might help work? You know, we’ve trained Armstrong in, in the open practice library, great open source repository, and it will just, which is a bit overwhelming ’cause there’s so many, so much stuff out there.

      But Armstrong will just give you three ideas. You can take it or leave it, but hopefully it just elevates you on that little bit more. And I think. This is where Armstrong can help. It can just get you going in the right direction. It could. We don’t think individuals, we think teams should use ai in their conversations.

      Let’s see what Armstrong thinks and see if Armstrong can get, get us going in the right direction and hopefully you’ll get a better collaboration. You’ll more informed or point you in the right direction thanks to the training that we’ve been able to get to our ai.[00:25:00] 

      Bella: It’s become a little bit of a catch phrase, hasn’t it? Like AI won’t replace humans, but a ai humans that use AI will replace humans that don’t. That’s the exact approach we’ve taken. Tim was talking about it’s not gonna replace real coaches insights, that level of context, not for a while anyway, we need generalized AI for that.

      But it’s certainly, there are all sorts of ways, Tim’s given a few examples. There’s a heap of, we’ve been looking at research grants and things to go a whole load deeper about sort of some really, really fascinating kind of front edge stuff that could start to really help teams communicate and collaborate at another level with just nudges and assistance and help.

      So I’m very, very excited about. How it can help all the people that we’re working with, but also just help us be more efficient and do a better job. It’s an exciting, technological frontier we’re at, I think.

      Alexis: I really love that. And I tell you a story about. What happens when a team of developer really [00:26:00] work on that. I’m working with a team of, of developer , basically I’m coaching the manager of the team. We discussed, their new goals because they are really shifting where they are going with their product. And it’s very challenging for the product. It’s very challenging. For the team. And it’s also challenging for the people themselves because they will need to grow new skills.

      They will need to do things, they never did. They are really experienced developers and I’m discussing both the goals for the product and the developmental aspects for each individuals. And I’m telling the manager, you should have really career conversation with all of them so they can really think, at a at time period, that fit them. That could be five years, 10 years, 20 years. We don’t really care where they want to work, what kind of jobs they want to do, and what kind of size of company and work on that really career conversation really long term. And he, he is really excited about it.

       And he discussed with the first developer about that. [00:27:00] And the result was really interesting because the developer came back and listen, that was a fantastic conversation. I loved it. And look at that. I created a series of prompts because your questions were really good and I’m well thinking. Yeah, I know that. I know the questions are good. And so everybody in the team can do that following that series of prompts. And I looked at it and said, yeah, of course they are developers. They know how to talk to a machine. So of course he created really good prompts and he tested it and they all worked on that.

      And the manager told me that was very funny. I, I’m chatting with one. And then the 10 others are doing that work. And now the conversation I had with them are really fantastic because they have really inspiring things to say and. All about that. So I can see how, considering Armstrong as another team member that have of course, more experience and more knowledge, and that could be really inspiring for the other team members and really enabling them to go further.

      So[00:28:00] I feel that’s a very nice way to integrate AI in that context of aligning, getting people to really work with each other, collaborate with each other effectively.

      Bella: Yeah, that’s one. One of the things we looked into was, again, in, in relation to the sort of the grants, is could you, could you have an AI coach facilitate? Through a, like a, a, a check-in meeting. ’cause something we’ve noticed, a real anti-patent that seems to happen a lot is check-in meetings, become a group exercise where everyone watches everyone else update the numbers.

      And it’s like, yeah, but you could do that beforehand. The bit that counts is the, so what does that mean? And the discussion. So could you. Without the need to have a human, which is obviously expensive. And you have to book the human and arrange it all. You know, there’s, there’s logistics there. Could you have something that’s sort of just like you were describing, like nudging you through the conversation?

      And then the brilliant thing is it can then learn and respond depending on what [00:29:00] it is and, and goes. It, it’s not straightforward. But there’s, there’s some, some things there which could. Hugely increase the quality and the the outcomes that come just from a simple half hour meeting, but not just that afterwards.

      You’ve just had an AI listen to everything that happened. What was the subtext of that meeting? Were there any dynamics? Were certain people doing certain things they didn’t realize were having an impact because they were focused on the content? All that kind of stuff can be surfaced as insights afterwards potentially.

      And this is where the coaching comes in, with some suggestions about what you could do to fix it. I mean, these. Complex things to do, but I think they’re not out of reach with ai, but the, the benefit that it could have, it’s just enormous. It’s so exciting. So, yeah, I, yeah, we’ll have to see. But yeah,

      there’s a lot of good stuff to done

      Alexis: Excellent. So a question that I usually ask to all the people who are building a product for others do you use Stellafai to, to build Stellafai?.[00:30:00] 

      Tim: Absolutely. Absolutely. And it’s, we learn so much from adopting it ourselves. We are our own alpha testers. Not just Stelfy, but, but OKRs. In, in, in all honesty, I have not used OKRs brilliantly before Stelfy. I, I loved the idea of them. I love the principle of them. But I, like many other people, I have not seen them work terribly well even when I tried them at previous organization.

      I know, I know why I’ve learned a lot from Bella, who, who brought all of the goodness , from Google. And I can see that, that the mistakes we were making but the, the best way to learn is to do to do it on, on their own content. And as an example, we so, so we have a weekly check-in. It happens at 10 o’clock every Thursday morning.

      Honestly, if we don’t do the check-in on a Thursday morning at 10 o’clock, it feels like I haven’t brushed my teeth. It’s become a ritual. We’ve done it since the beginning of the company and, and we’ve evolved. So yes, we, we use our platform. We review our key [00:31:00] results. We update them. We have a conversation.

      But as Bella was saying in the last question we’ve learned actually, why are we wasting time in this, this precious time together as a team? We’ve only got 25 minutes. Why are we spending time trying to figure out the calculations and get the numbers right? We’ve, we’ve emerged from that and, we now entered before that meeting and actually something I’ve noticed just in the last few months is that the updates are happening during the week.

      ’cause we have a Slack integration,, we can see when anybody updates a key result or makes a comment, it, it fires out a message to the team. I think this is a transition we’ve gone through, that we’re now starting to think about what is the measure that we’re trying to move today.

      And when something happens that we know it’s moved, one of our measures, the first thing we wanna do is go and update it. So it’s become less of a, of a batch thing that we do once a week or a ritual and into a continuous thing that is just a part of our. Kind of cognitive way of [00:32:00] working. And I see this with other practices.

      It’s like going from fortnightly retrospectives to a realtime retrospective. You know, why? Why are we waiting two weeks to do a retrospective? We could just have a realtime one running all the time, or abandoning the daily standup because there’s such good collaborations, pairing and mobbing. You don’t need to stand up.

      And I think it’s a similar thing we have used OKRs with the ritual, with the guardrails, and now we’ve been using ’em for a couple of hours. I’m now seeing the team who are, who are just naturally thinking about what’s the key result that this, that, that I’m going to move today?

      And how is that gonna help achieve a goal? And what’s that goal connected to in terms of a bigger strategy? And that’s just becoming a part of default

      Bella: You are what, what you’re describing and, and it’s really interesting listening to you say this ’cause we haven’t had this conversation, but what, what you are describing is like another level of outcome obsession. It’s driving everything, every micro decision all the time. Is that gonna move one of our needles?

      And [00:33:00] yet, if you’ve got the needles right, which is why you need to put a bit effort into setting them, that’s

      Tim: got, we got them wrong at first. Remember our first quarter, we, we got, we got them wrong. So, so we, we’ve come through that journey as well. Yeah.

      Bella: Well, you let, I mean, part of that is we were new founders, so we didn’t know what we should and shouldn’t be doing, which is a whole nother podcast. But yeah, the, the yeah, like we’ve got so much better at figuring out what are the right OKRs for us. One of the things we’ve had from a lot of organizations is we’re too small for OKRs.

      Like it’s, it’s not gonna be valuable for us. It is true that you get to a, when you get to a certain size, and we reckon it’s about 2050 to 20 to 50, depending on the org from the people we’ve spoken to, you get a level of communication complexity with all of the interconnections. You know, it’s a great exponentially that suddenly you need a system to help you operate and stay aligned and communicate. And one of those systems could be OKRs, [00:34:00] but it doesn’t mean that it’s not profoundly valuable at a smaller scale, it’s just that it’s not critically needed to make sure you are still able to keep moving forward. So yeah, we, we 100% use them. . 

      Alexis: That aspect of complexity that comes with adding people to the team that usually we completely ignore. That’s very funny that suddenly people are highly frustrated because that doesn’t work anymore. When you look at it from the outside and you, and you lived it before, it’s so obvious.

      I was discussing with the founder of a company and he told me, I don’t understand why we just have two more people on the team and suddenly it seems nobody understand anything anymore and nothing changed. I told them, yeah, okay, good. Let’s look at that. Nothing changed. And they added the two people, but they took also another office because of course, two people in that previous office didn’t fit.

      So now they are spread into two offices.

      Look, that’s, so before it was annoying because[00:35:00] developers needed to work close to people who were on the phone calling customers, and that was very annoying. And now you split them in two rooms. And and you are surprised , that was so funny.

      And of course I cannot say it this way. I’m, I’m more gentle and I’m making it emerge more gently to avoid being thrown out of the window. But that’s, that’s very interesting to, to look at it. Yeah, that’s it. So putting in place a system that will enable people to do great work is really important.

      And what I like is you really thought that through and using it yourself makes, makes it better. So I really like that. I would like to touch on something slightly different. I’ve noticed you, you both have strong commitment. Diversity and inclusion and I would like to know how shape the, the culture and maybe even the strategic direction of 

      Tim: In our company we felt there are some principles that we have to start from the outset because it’s not [00:36:00] something you can retrofit in later. Diversity and inclusion is something, we were both passionate about. And Bella, I, I know from the work that she did at IBM , where we first met, I knew that this was going to be a really strong partnership in that.

      It was something that she would really drive and something that’s really important. And that was important for me when I was, you know, seeking a co-founder that I wanted to, to work with. We probably spent about four months before we even hired anyone to write code or build start building products and things like that.

      And a lot of that was about finding our why and our purpose. And we, we used practices on ourselves, like business model canvases, again, just to trigger the conversation and to get the alignment. But that was something from, from early on around around diversity and inclusion and also sustainability.

      You’ll notice in pictures of us, we have a, a, a lot of our own swag. We have a lot of our own t-shirts and hoodies and things like that. Our suppliers that we use for that , had [00:37:00] good sustainability metrics because we thought we could play the card that we are an early startup, we don’t have much money, let’s just go for the cheapest thing possible.

      Let’s not worry about where it’s made. But we thought that’s gonna be so hard to turn out. You know, it’s something we believe in. If you don’t follow your principles and your values from upfront, you’re lying to yourself. A lot of that comes around a, an alignment, again, alignment, shared understanding, communication, collaboration about what those principles are, and then figuring out then what, what are, what are the initiatives?

      What are, what are the acts that, that we, that we can then put in place? I think we, we’ve started I think there’s probably more like everyone that you’re never done with these things, but we started and, and, it’s, it’s something that you can continuously improve and continuously evolve in, in the next chapters and the next version of the, of the company.

      Bella: When we did our first sort of recruitment campaign, campaign might be too big a word. We’re only little, but we, one of the first things, so, so Tim and I do both care about this. So the very first version of our [00:38:00] website, I think I had like four pages, and one of those pages was a diversity statement and about just setting out our intent.

      But I was really interested when we put our first sort of ad out, we were looking for a a junior designer. We got you. All these things are benchmarked around how many, how many responses you typically get, and of, of like certain underrepresented, underrepresented groups and the applications.

      We got so many people that I spoke to often, women, maybe people that had a slightly different educational background and. Said when they, we asked them to write just an answer to two or three questions around what attracted them to Stellafai, and I’d say every single person that wasn’t like a young white male, came back with a, I was really, it was really cool to see the, the diversity statement that attracted me to your company and, and it’s a sort of.

      It’s a self-fulfilling prophecy. If you care about it, you’ll attract people that care about it. And then you’ll create [00:39:00] a more diverse and inclusive culture, which, you know exactly what Tim was saying. You have to do it from the get go. And we did. And then it’s also not just saying it, it’s doing it.

      There’s an awful lot of kind of they call it pride washing in pride month, where, you know, all these companies change their logos to pride. But if you look at their actual way in which they, the things they do, I mean, it’s. It’s the very minimum they can get away with. They don’t actually do, do any, their actions do not suggest they care, their actions suggest they want to cash in on looking like they care.

      Now, that’s not all companies, but, but like, you have to actually then do it in the organization. So the, the other thing mean, Tim and I are really lucky, like the experiences we’ve had and things like, you know, the open practice library and all these practices, design thinking, et cetera. So many of them, you know, dot voting for example, 1, 2, 4 all.

      These are all things that help give everyone a voice in a non-threatening way. And so it’s how you then operate and how you work. And then [00:40:00] that’s expanded out to our, our customers and our clients as well. And we talk to ’em about know. If you want people to be engaged, you need to make them feel like they have a voice and included, and, and this extends to the role you are doing as well as some of the more, you know, traditional DEI ERG, so employee resource groups and, and things like that.

      So we’ve tried to not only do it, I mean, we’re in a small company and Tim and I are pretty experienced, but we’re always learning. So we’ve tried to do all of those things, make sure that everyone has a voice, and we have lots of forums where we listen to that. But also in the work we’ve done externally, try and reinforce those values and those principles in how we run our workshops and how we advise and coach people do these things and here’s why.

       The business case for inclusivity and trying to bring in a diversity of voices is like a no-brainer. But sometimes people don’t know how to make that transition and they don’t realize it’s on a, it’s everyone’s responsibility in how you operate every day, not just. The, the HR group in your organization?

      We’ve seen the benefit of that in terms of [00:41:00] the talent we’ve had into organization and the diversity of people. We have 50 50 male, female, et cetera, et cetera. And but we’ve also tried to take that out and be ambassadors for those ways of working and those ways of thinking.

      It’s very cool to have a partner like Tim to do that way 

      Alexis: I love it. And people will not see that because there’s no video. But I was smiling and nodding as you were talking, because I believe it’s very inspiring and you gave really the, the right, things to inspire leaders to really do something about what, what they can control and to make it happen.

       To close , the session, what advice would you give to new leaders or aspiring leaders

      Tim: yeah. Wow. I would say simply collaborate. Get your people together. I. Get, ideally get, get your people into a room and get ’em [00:42:00] talking. That naturally giving it, it builds on several answers we’ve talked about today, but it’s, let’s get everybody talking to each other and I, you’ve, you’ve got something in common.

      You all work for the same organization. You are hopefully working towards a common mission. And if you’re not. By getting people talking, getting people communicating and collaborating. You will start to align. You will start to get shared view. You’ll start to identify where those slight nickles of misunderstanding are happening.

      That’s the starting point. Just just getting people to talk to each other. Then I would go level Steve about, well, you know, what are we trying to do? Why are we here? What, what, what are we gonna tackle? How are we gonna prioritize? Let’s prioritize, let’s measure. That can come all afterwards, but unless people are comfortable talking to each other, collaborating, challenging, ideating.

      Building upon you know, that is the foundation for success. So whatever it takes in a, to get those people into a [00:43:00] room. Good facilitation, good setup, good planning to to, to put that environment in place to facilitate collaboration. That’s what leaders should focus on doing right now at the beginning of the new year.

      Alexis: Excellent. Thank you.

      Bella: Predictably write some OKRs. Yeah, like that. Actually, let me rephrase that. Think about what outcomes you most want to achieve and narrow down that list till you’ve got like Warren Buffet gives us advice. He says like write your to-do list, and then scratch up everything that’s below number three. Like same thing, like lots of people say it in different ways, but, but you’ve gotta prioritize ’cause you can’t do it all.

      So prioritize and, but make it measurable. The biggest mistake I made when I first started moving into leadership roles is I tried to carry on doing everything that I’ve been doing before and then take on all the extra. And that just ended up with me being like, on this very fast moving hamster wheel and just like.

      Yeah, [00:44:00] it’s, it’s not a, it’s not a good place to have great insights and to be a good patient listening leader. So you’ve got to trust people to take things off you and to create time for you to reflect and think. And part of that reflection is figuring out what the priorities are and then making sure to Tim’s point that you are communicating and collaborating well to, to deliver them.

      And then the last thing. I think this is, you spend a lot of time at work, you’ve gotta make it fun, like find ways to enjoy yourself, to have a laugh. Like in Stellafai on the Friday standup, we always, we all pick a random filter on these Google filters, so we all turn up as like pirates and cowboys and astronauts floating in space.

      It’s a silly little thing, but find ways to make it. Make it fun. Like if you, if you know, you’re clear why you’re collaborating and you’re feeling engaged and connected, and then you are having fun as you do it, the [00:45:00] difference that makes to our working lives is pretty, pretty, pretty phenomenal. So, yeah, set OKRs, find time to reflect and stand still and, and lead , and have fun.

      Alexis: I love. Thank you to, to both of you for having joined the podcast today. Have a great one

      Bella: Thank you very much. It was great to do it. Thanks, Alexis 

    • The Art of Thinking: 25 Insights into Human Misjudgment from Charlie Munger

      The Art of Thinking: 25 Insights into Human Misjudgment from Charlie Munger

      In “Poor Charlie’s Almanack,” Charlie Munger analyzes the psychological factors that lead to poor decision-making. Known as the 25 standard causes of human misjudgment, these principles provide invaluable insights into why people think and act the way they do. As a leadership coach, understanding these causes can be transformative in guiding teams and individuals toward better decision-making.

      1. Reward and Punishment Super-Response Tendency

      People are strongly motivated by incentives. Understanding what drives an individual or a team can significantly impact leadership and management strategies.

      2. Liking/Loving Tendency

      We tend to favor decisions and actions that involve people or things we like. This bias can cloud our judgment in professional settings, especially when dealing with friends or favored colleagues.

      3. Disliking/Hating Tendency

      Conversely, we often irrationally dislike and avoid people or things we have negative emotions towards, which can lead to poor decision-making.

      4. Doubt-Avoidance Tendency

      Humans naturally dislike uncertainty and tend to make quick decisions to resolve doubt, sometimes at the cost of rationality.

      5. Inconsistency-Avoidance Tendency

      Once we’ve made up our minds, it’s hard for us to change our beliefs and actions, even in the face of conflicting evidence.

      6. Curiosity Tendency

      Our inherent curiosity drives us to explore and understand the unknown, which can be a powerful tool in learning and development.

      7. Kantian Fairness Tendency

      We are naturally inclined to act in ways that are perceived as fair by society’s standards, which can influence our decisions and behaviors.

      8. Envy/Jealousy Tendency

      Envy and jealousy are powerful emotions that can significantly influence our actions and decisions, often negatively.

      9. Reciprocation Tendency

      We feel obliged to return favors and kindnesses, which can be manipulated in various social and professional contexts.

      10. Influence-from-Mere-Association Tendency

      We are easily influenced by associations with past experiences or emotions, which can lead to biased decisions.

      11. Simple, Pain-Avoiding Psychological Denial

      Sometimes, we choose to deny reality when it’s too painful or uncomfortable to accept, affecting our judgment.

      12. Excessive Self-Regard Tendency

      We often overestimate our abilities and worth, which can lead to overconfidence in our decisions.

      13. Overoptimism Tendency

      A general tendency to be overly optimistic can skew our perception of reality and lead to unrealistic expectations.

      14. Deprival-Superreaction Tendency

      We react intensely to being deprived of something we already possess or believe we deserve, affecting decision-making, especially in negotiations or losses.

      15. Social-Proof Tendency

      We look to others for cues on thinking and acting, especially in uncertain situations, which can lead to herd behavior.

      16. Contrast-Misreaction Tendency

      Our perceptions are heavily influenced by contrasts rather than absolute scales, affecting how we evaluate options.

      17. Stress-Influence Tendency

      Under stress, rationality often takes a backseat, leading to impulsive and poor decisions.

      18. Availability-Misweighing Tendency

      We give undue weight to information that is readily available to us, regardless of its relevance or importance.

      19. Use-It-or-Lose-It Tendency

      Skills and knowledge must be regularly used and refreshed or deteriorate.

      20. Drug-Misinfluence Tendency

      Substance abuse can significantly impair judgment and decision-making.

      21. Senescence-Misinfluence Tendency

      Our mental faculties can decline as we age, affecting our decision-making capabilities.

      22. Authority-Misinfluence Tendency

      We tend to respect and follow authority figures, sometimes blindly.

      23. Twaddle Tendency

      Humans have a tendency to focus on irrelevant information or engage in meaningless chatter, distracting from important decisions.

      24. Reason-Respecting Tendency

      People are more likely to follow advice or instructions if they are given a reason, even if the reason is not particularly compelling.

      25. Lollapalooza Tendency

      Multiple biases acting together can compound and lead to extreme outcomes, for better or worse.

      Conclusion Understanding these 25 causes of human misjudgment can significantly enhance our effectiveness as a leader and decision-makers. By recognizing these biases in ourselves and others, we can make more informed, rational decisions and guide our teams toward greater success.

      Have a read at Talk eleven for more details: https://www.stripe.press/poor-charlies-almanack/talk-eleven

    • Cloud Infrastructure Leadership: What Changes When You Lead the Platform

      Cloud Infrastructure Leadership: What Changes When You Lead the Platform

      Cloud infrastructure has changed radically in 20 years. We moved from standing in line to request hardware to provisioning global resources in minutes. Yet the leadership challenges didn’t disappear. They evolved.

      In this episode of Le Podcast on Emerging Leadership, I’m joined by Michael Galloway, a platform and infrastructure leader with experience at Yahoo, Netflix, and HashiCorp. We explore the evolution of infrastructure, but also the human side of platform engineering: trust, ownership, change, and the realities of operating systems at scale.

      From “tin” to cloud: speed increased, responsibility didn’t vanish

      Michael shares an early Yahoo story that captures the shift: the era of physical requests, committees, and scarce resources. Virtualization and cloud unlocked a new world, but they didn’t erase complexity. They moved it.

      The question is no longer “How do we get machines?”
      It becomes: “How do we design defaults, behaviors, and systems that make operations reliable?”

      “Don’t just use the interface”

      A key theme in our conversation is what happens when abstraction goes too far.

      Michael learned early in his career that using an interface without understanding what sits underneath limits your ability to solve real problems. The same applies to internal platforms and infrastructure products: if teams can’t see what’s under the hood, they can’t operate their services confidently in production.

      This matters for DevOps and full-cycle ownership. If the platform hides everything, it also centralizes responsibility again. And that’s exactly the anti-pattern many organizations are trying to escape.

      Setting the right defaults (instead of hiding complexity)

      Michael makes a distinction I find extremely useful:

      • Abstractions can help with the zero-to-one problem (get a service running fast).
      • But sustainable systems require teams to drill down, understand decisions, and troubleshoot effectively.

      His closing line on this topic is simple and sharp:
      Predictability is more valuable than velocity.

      A crisis story: ownership, outcomes, and early wins

      Shortly after joining HashiCorp, Michael faced a real incident: a workflow engine falling behind at scale, with work piling up and trust already eroded. The technical work mattered, but what stood out was the leadership sequence:

      1. Take ownership publicly
        People need to hear: “We own this, and we will fix it.”
      2. Form a durable team around the problem
        Not a temporary war room. A team with a mandate.
      3. Define outcomes that matter
        Not “deliver X,” but “stability,” “scalability,” and “confidence.”
      4. Deliver early wins
        Not a 24-month plan. Evidence now, then progress each week.

      That combination rebuilt credibility and made it possible to redesign the system properly.

      Change at scale: the lesson of urgency

      We also discuss a platform adoption challenge from Michael’s Netflix experience, and what he learned about change management: good ideas don’t spread by themselves.

      Two levers made a huge difference in later roles:

      • A real deadline (a cliff, not a wish)
      • Executive alignment to keep that deadline real

      Michael’s practical insight:
      A target like nine months is close enough to feel real, far enough that teams don’t immediately say no.

      Advice for emerging leaders

      Michael closes with three themes that translate well beyond infrastructure:

      • Understand your stakeholders deeply (including what isn’t said)
      • Deliver a meaningful win in the first 90 days to earn credibility
      • Define the purpose of your team so priorities become easier and autonomy grows

      Here are a few links:

      Here is the transcript:

      Alexis: [00:00:00] Welcome to Le Podcast on Emerging Leadership. I’m your host, Alexis Monville. In this episode, we are excited to welcome Michael Galloway, a visionary leader in the tech industry with over two decades of experience. Currently shaping the future of cloud infrastructure at HashiCorp, Michael brings a wealth of knowledge from his dynamic roles at companies like Yahoo and Netflix.

      Today, he shares his journey, insights on platform engineering and the evolving landscape of technology leadership.

      Welcome to the podcast on Emerging Leadership. Michael, how do you typically introduce yourself to someone you just met?

      Michael: Yes. Thank you for inviting me. Alexis. The way I think I typically introduce myself is I live in California. I’ve been working in the tech industry for about 20 years. Father of two rambunctious girls and husband to a wife of [00:01:00] almost 20 years now.

      Alexis: Wow. Wow, wow. I would love to unpack all those things, but maybe we’ll time for, for some of it. Let’s look at your, your journey in the tech industry. A fascinating journey. I’ve heard about your experiences both at Netflix and now at Hashicorp. Could you give us a, a snapshot of your trajectory and what drew you to that field of cloud infrastructure?

      Michael: Sure. Well, like I mentioned, I’ve been in the industry for more than 20 years. I was actually part of the early two thousands crew at Yahoo. Just before the Google IPO. So that was an interesting experience to start off my career. yeah, that was you know, everything, everything was possible.

      And some of the most brilliant minds that I have the opportunity to work with many years later in my career started there. In fact, my current boss at HashiCorp was also part of that crew back at Yahoo and And and, you know, it’s, [00:02:00] it’s, the Valley is ultimately very small from Yahoo. I went through a number of different ranges of companies.

      So I actually did a startup in the enterprise software space, which I was fortunate to sell. I would say it’s more of an Acqui-hire but it was a great experience to go through what is a startup life like in Silicon Valley. Eventually, I landed in Netflix around 2016. And moved into the platform engineering organization. From there I led a bunch of teams in Delivery Engineering. I think the most famous part of Netflix that people may know of is the Spinnaker product that was developed for the most part between Netflix and Google. And that’s what we evolved and, and worked on. After that, that was really where I fell in love with platform engineering as, as a concept.

      The whole concept of full cycle development and DevOps as we were pioneering it at Netflix was just fascinating and working with some of the greatest minds I I’ve had the opportunity to work in that space. I eventually moved to leading platform organizations [00:03:00] at mid-tier companies, and now I’m over at HashiCorp. Running the infrastructure part of the organization personally. you asked about infrastructure. Infrastructure specifically is a fascinating and evolving space. You know, I actually have experience going in front of David Filo, one of the founders of Yahoo, and making physical hardware requests.

      I remember standing in line a little anecdote there as I I was we all queued up at, at, at, at these hardware request committee meetings. And David Filo is one of several members. And I was right behind this gentleman. I had just started my job. Maybe I was a month, two months in. And the, the person in front of me was from Yahoo Photos, and he goes up to David Filo and he’s making requests for several multimillion dollar filer machines that we needed for the Yahoo Photos footprint. And they discussed and, and, you know, okay, we will ultimately approve. And then my number’s called, and I, I get up and. I said, I’m, I’m looking for $300 to buy a hard drive for one of our [00:04:00] machines. And Yeah. Philo had this look on his face of like, yeah, maybe this, maybe we can do, do some efficiency improvements for this meeting.

      Might not be the best use of everybody’s time. And I say, I, I really appreciated that he saw it that way. But you know, the, so I was, you know, I think a lot of us have experience with the actual tin, but now, but with the introduction of virtualization that really came out many years later, unlocked, you know, all kinds of, of capabilities like you know, immutable deployment patterns and, and real ephemeral infrastructure started to become a thing. And, and finally I think. So, so what we’re seeing is, is the outcome of those innovations and the, and the, this idea that you can allocate virtual global infrastructure in minutes. But I truly think that that’s actually just the beginning of where, where we’re headed as an industry. So it’s an exciting space to be.

      Alexis: Oh, whoa, whoa. Wait, that’s, that’s very [00:05:00] interesting because yeah, with, the introduction of virtualization, basically a lot of people thought, oh yeah, that you, you don’t need to care really about cloud infrastructure anymore, and.

      Michael: Right,

      Alexis: Anyway, everything will be fine with, that’s just infrastructure as code and, and let’s, let’s do everything.

      But that’s not really what happened. Even if we I don’t remember DevOps. It’s what, 2009? Something like that. We are still not there yet. Completely. In your, in your, during your talk at Plato Elevate you mentioned that. Cloud Infra was not about hiding complexities, but setting the right defaults.

      I would like to you to discuss that a little bit more, because that will maybe tell us what, what is coming, what, what the future looks like.

      Michael: Yeah. This is a very fascinating conversation. It’s, it’s something that we can quickly get into Modern applications and lose a sense of principles. So I [00:06:00] like to come at this more from a principles first approach than, than just you know, the common conversation that I hear in many platform organizations or many companies is, how do we become, should we present a Heroku environment? And I think that that’s missing some grounding. you’re talking about how to use it. As opposed to the philosophies of behavior that you want to encourage or support in an organization. So like everything else in software development, the answer is maybe The answer is nuanced, right? But let’s start with the an early, I’ll give you an early story that, that really grounded my thinking on this. It goes back to my Yahoo days actually. So I was a software engineer there and I worked on the Confabulator product. It was a Desktop Widgets product that worked on both Mac and Windows. Actually, the modern Apple widgets experience on the iPhones, as well as Netflix’s tv or Netflix’s video capabilities on tv. And, and all the modern TV [00:07:00] widgets all are actually born from some of the actual same humans that worked on Confabulator. I, I actually worked with some of those guys.

      One of ’em I actually hired into to Yahoo. So just a little short history there. So all things are connected, but I was working on this and I was around much smarter minds than mine. And one of the lead engineers in the group emphasized to me, he said, don’t just use the interfaces to these libraries that, that are, you know, available to us from the, the, the TVs or from the, the OSS systems that we’re trying to operate on.

      Don’t just use the interfaces. You said you need to understand What they do underneath, you need to understand those in order for you to be able to solve the real problems, the hard problems. And he was right. How often we end up grabbing a library and just using it without thought of how is it actually performing these actions.

      And when you do that, and we’ve seen this in software development all the time, where you have higher and higher level frameworks, and [00:08:00] the understanding of the magic underneath is ultimately .Limited to the few that actually care to try to introspect, and some of those frameworks actually actively try to encapsulate and block the ability for you to really understand what’s under the covers. Why does that matter? Is because if it fails to do the thing I need it to do, if my application calls into an interface and for whatever reason that interface has an unexpected side effect, I now have no ability other than to just abandon that interface. To solve that problem. And that becomes really a, a limiting factor. So if you take it from that perspective and you, you, you view software platforms and you view infrastructure platforms or platform engineering platforms, they’re all the same concept, right? They’re encapsulation their abstraction. There’s the same software principles. You start to get to the point where you realize, where do you want to put The responsibility for resolving and solving problems. In a true [00:09:00] DevOps world, you ideally want to enable application teams to ultimately have the ability to understand and operate their products in production. And if you don’t, don’t enable them to be able to see below the details for how something is being done. They have no ability to perform that task. They have to rely on a central team to do it. just like if I am, if I am the provider of a framework, but they can never see into the code of that framework. If that framework fails to do the thing they need to do, they’re going to abandon it or do something different, which will create heterogeneity in the environment and more complexity. So when I think about the right experience, what I look at is Not about hiding the complexity per se. I think you can follow abstraction or present a an interface facade if you want to simplify the zero to one problem that most of the time, this is what they’re talking about. I just wanna get my application out.

      I just wanna get a database. I that’s a zero [00:10:00] to one problem. Provide a simple facade. That’s where the abstraction actually can have value, but. It should be an abstraction that you can drill further down if you want to. You can go further and you can see what actually was done. How did how does this machine perform the actual instantiation of that database? What is the instance size? If it was, say, Amazon, of that database that was set up, I should be able to introspect these things because those can lead to me understanding why a failure occurred. In my production system or how better to architect. A good example of this is a situation that we just recently encountered you know in, in my current universe at HashiCorp, where one of our products has a stateful, it wants to perform in a very stateful way. Well, it is a stateful application. And stateful is a particularly tricky monster to, to from an infrastructure standpoint, right? We really, [00:11:00] very much on the infrastructure side, wanna see the world as I. As, as cattle they say not pets, right? That’s a common euphemism. And and so the idea that I can truly lose or blow away my infrastructure if I needed to and that the resiliency is actually supported both at the application tier as well as other parts of the infrastructure to support the idea that any virtual thing can fail. And the truth is, is that whether anybody likes to think of it or not, I have a lot of experience with yeah. Virtual things fail because physical things fail. So you very much need to have that. If you a stateful application doesn’t like to operate that way. It likes to believe that, that there is a permanence with the thing that it’s in. This is a really tricky problem with infrastructure systems to date. If we have a full abstraction of what is actually happening on the infrastructure tier, especially when we need to version the infrastructure underneath the covers, it can, [00:12:00] it can be a real problem for that, that application team, because they don’t understand why systems are periodically being disconnected or broken or having any predictability around it. So as a result of that, they have to offload all of the operation problems and all of the ops that are specific to their application universe, to the central and infrastructure, the central infrastructure team. And that is the anti-pattern that we all wanna avoid, that the whole point of DevOps was to move out of a central team operating applications in production as much as possible. So that was a long-winded answer. The short nugget here I would say is predictability is more valuable than velocity.

      Alexis: Mm. Yeah. , I guess that that summary helps really to to understand the, the whole thing. Could you tell us about a particular challenge you, you facedworking on that realm of cloud of platform at Corp and how you approached it.[00:13:00] 

      Michael: Yeah I’ll give you a different challenge ’cause life’s full of those. When I joined Hashi Corp let’s see, I joined December of 2022, so December last year. So I’m almost at my one year anniversary actually. About a month and a half in, I would say, so sometime in January all these alarms started going off. It was not my fault. I had just started. That’s okay. I don’t mind if it is. But it was not alarms are going off all these, you know, 3:00 AM things blown up. And so the issue was a big portion of our System relies on a workflow. It, it’s basically, it’s a workflow engine that, that a lot of our use cases require to be operating effectively.

      It’s a, it’s a, the engine’s cadence, it’s used, it’s pioneered by Uber. And temporal is, is maybe a more well known modern name is a, is a Next iteration of that workflow engine. Anyway, [00:14:00] so this thing started to blow up, and the reason it started to blow up was that it was backed by a, a single, very hard, a large database instance. And that database instance was struggling to, to keep up with. An unanticipated load. And this was not necessarily a new issue. In fact, cadence had rather this, this, nothing to say about the cadence Service is perfectly fine workflow engine, but the design was just not well des it was not well designed to be very scalable. And so as a result over the last several years, people had kind of wanted to avoid This system ’cause it was known to be problematic and it had burned people out trying to support it. So, but it had finally tipped over and, and by tipped over, I meant it actually stopped keeping up with the abil, all of the workflows coming in.

      So it started building a history list. I think something on the order of maybe a million. Runs behind and it was continuing to fall behind. Yeah. So, you know, when you see that it’s, [00:15:00] it’s a downward spiral, right? It’s, it, it, and so we brought in AWS people and we performed a quick crew. I. To, to set up basically like a war room situation, to try to triage and stop the internal bleeding.

      And so what’s the first thing you do? You say, okay, well let’s, let’s, if we can’t horizontally scale because we hadn’t sharded this system, let’s scale up. Right? And whenever I hear scale up, I think all of us, and especially in the infrastructure space, kind of cringe ’cause you know, there is a finite limit to scaling up and scaling up. Doesn’t actually solve the underlying problem. Ultimately it just delays the problem. yoU know so we did, there’s, again, our first focus was stop the bleeding. We scale up. It, it helped. Still some things were, were not quite as stable as we wanted. anD this is where I think the more interesting part of the story it comes in because all these kinds of technical problems in my whole 20 year experience. I’ve very rarely been [00:16:00] on what I would consider you know, a Mars landing kind of problem where you’re maybe doing something fairly novel and even that maybe isn’t as novel anymore because we’ve done it before. Uh, most problems are not, in other words, insurmountable technical problems, where there just is no answer. generally, I’ve found that 99% of problems that I’ve had to deal with are more about organizational problems. And, you know, you might even go to say leadership problems in the sense of how do you, how do you think about approaching this kind of crisis? What are the right things to do when a crisis like this happens? And so the steps we took first, the very first thing is recognize that. Upper leadership partners, customers who are relying on this thing all want somebody to say, I’m gonna raise my hand and say, I’ll take ownership of this problem. That’s the very first thing everybody needs. They need to hear you

      Alexis: Mm-Hmm.

      Michael: And so [00:17:00] we did. I I basically said, okay, we recognize this as a problem. I’m not gonna make up stories about this. It’s a problem and it needs to be resolved, so we’re gonna take ownership of it. And what we did was formed a permanent team around this. And that sent a very clear signal, we’re gonna own this problem.

      We’re going to move it to a, a place where you can trust it. anD that was actually a really important thing, not just for the ownership aspect, but there was real lack of trust in building these, these workflows by teams because of the instability history. And so, as a result, teams started to look for alternative approaches, and that would’ve led to a much more complicated universe to manage. So it was very important that they, they knew somebody was going to own solving it. Once we did that we defined some specific outcomes towards stability and scalability that we needed to be able to achieve. It needs to be horizontally scalable, not vertically. I think that was one of the most important things that we emphasized, that the thing we did today [00:18:00] to bandaid, this is not a solution. It’s, it’s a bandaid. What we need is not to try to put all our cargo on one ship. We need multiple ships. And, and so once some of the fundamental, and these are not complicated concepts, but they are complicated to execute on because having multiple ships means a whole lot of additional complexity and logistics up front for figuring out what goes on those ships and so on.

      I don’t know, I just suddenly jumped into a nautical analogy. But these, this is You know, establishing this is what we are, are, this is our success criteria, this is our strategy was critical to get out early. What are the outcomes, not the physical deliverables. The next thing we had to do deliver short-term wins. And by that I mean short term, what anybody ever cared about was stability in, in the short term, as well as enabling products to launch. So the products that we’re afraid to Right on this. We [00:19:00] immediately engaged them, prioritize, making sure that they were stable. They had the resources within the system to be reliable.

      And so we enabled those product launches. And then we pumped out every week what the reliability status was, what were there any issues and any updates or communication on progress towards those outcomes that we had. This was critical. Those two things were vital for us to establish credibility and for people to actually feel like the wind had changed and that this ship was actually going to turn that built.

      Confidence and trust gave us momentum. And, and as we continued to execute, this team has completely revamped the architecture, the system. They’ve migrated a bunch of the critical systems to starting to be able to Have better resource isolation, which are fundamental things in an infrastructure universe to be able to isolate workloads and manage resource consumption by each of those workloads. We didn’t have some of these fundamental abilities before. Now we’re in a state where we’re executing on the we’ve moved away from RDS and we’re bringing in. A scalable [00:20:00] backend, which is, you know, a, a Cassandra backend, which will allow us to horizontally scale. So we’re in a much different space, to the point where a leader about a week ago said to me ” not only do I no longer worry about cadence, I, I’ve basically entirely forgotten that it was ever a problem”. wHich is great except that I said just make sure that we don’t think we can remove people from this team right now. I’m glad you are confident.

      Alexis: Yeah, exactly. But yeah, I, I believe that’s, that’s very interesting. The what, what you offer as a solution. If I put aside the technical solution I, we could apply that to basically a lot of different problems that we have. Having a team that is able to say, okay, we are owners of that thing. And now we own that problem and we will solve it.

      Being really clear about what are the outcomes, where we are today, how we measure those ourselves compared to those outcomes. That’s very, very critical. And and [00:21:00] knowing that you will not win the trust of people by announcing 24 months plan. You will win the trust of people because you are delivering something now.

      yes.

      Michael: yes. 

      Alexis: Getting into that mindset is critical also. So I, I love what you’re saying about all that. Have I missed anything in what you, what you propose?

      Michael: No, I think you sum some, summarized it exceptionally well. I will say generally this you are, I fully agree with you. This is not a unique situation. This is a pattern and a strategy for approaching a, what is, what comes up fairly often in every job I’ve taken, there is always a crisis and I’m going to misquote the person.

      But it’s what I think the famous saying is, never let a good crisis go to waste.

      Alexis: Yeah.

      Michael: these are hugely valuable opportunities to actually have a tangible impact on the business.[00:22:00] anD you know where others may be afraid to tread. These are the opportunities that really enable you to shine as a leader.

      Alexis: I, I really like that. Are there other pivotal moments in your career when, when you, you really learn something significant about change and leadershIp? 

      Michael: Oh my gosh, yes. Well first, if anything I’m saying here sounds at all polish, please understand it comes from the many battle scars that I have over my history of, of making mistakes and reading and learning from, from the wisdom of others, and then having the opportunity again to apply them. But yes, let me answer your question more directly.

      So at Netflix .We and delivery engineering embarked on this initiative called Managed Delivery. It was a very ambitious project that is still very near and dear to my heart. It’s it’s, it’s fundamentally what it is, is delivery in [00:23:00] Spinnaker is done using pipeline, basically articulating pipelines. And what we found from From the way that we were operating where every team was defining their own pipelines. In Spinaker, I think we had about 16,000 pipelines at that time. We across about 4,000 applications, about 400 teams was about the size we were at. Platform Engineering has some challenges. One of the specific challenges was as we, we were still very VM based as we would release new base OS AMI s. That might include security improvements, patches, other things that needed to be there. We had an adoption rate of it took on the order of months to years for certain patches or updates to be rolled out. That was really problematic for us because you can imagine that there is, sure. I mean, if you did a security sev one incident, they could broadcast across the company and people might take action, but that’s a pretty disruptive thing to do. [00:24:00] What you want is, is a design that helps enable the, the bottom tier to be as evergreen as possible.

      Right. But we had a, we had a problem. All the teams owning their own pipelines Spinnaker had no intelligence about those pipelines. It, it just knew, run this, it, it was a workflow engine in many ways. Right. Run this step if that step Gives me a green light. Go to this next step, go to this next step, and, and maybe some conditional logic, but what do those steps represent? And, and what is the confidence after you know, step two as to whether this, this new update is safe to roll out? All of that was opaque to the engineering system. So what we needed was a way that we could evolve our infrastructure and we could evolve our amis, we could evolve our strategies under the covers. anD do so without having to get all the teams involved. So that was one of the motivations. Another motivation was we thought it would make it easier for [00:25:00] teams to also not need to articulate or come up with strategies in their pipelines for safe delivery, right? We teams would deliver applications to multiple regions. What’s the right sequence of steps that would enable you to catch a problem and roll back the change? If, if a failure happened in, say, the second region you rolled out to, which is a very complicated problem, right? First region successful, second region fails, most of the time pipelines would just die. And now you have this very confusing universe where you have different versions of your shafter running and, and problems

      can surface. So we thought, Hey, let’s take that problem away from teams two. Let’s create a declarative form of delivery that basically enables people to define the Criteria for success that would enable promotion from one lower environment to higher environments.

      That was essentially the goal of managed delivery, was move them towards the description of what needed to happen as opposed to defining how it should happen. [00:26:00] Very ambitious on the size that I was mentioning, especially because Netflix culture very much operated with a freedom and responsibility concept, and so that meant that teams were never Really obligated to use a service or a new system. So imagine operating in an environment where you have lots of very smart and talented people from all around the world that are working on their problems, their projects, and you ask them, you, you need to engage them on something that they honestly would prefer to not really have to think about.

      Right? I don’t con like, it, it, the water company doesn’t reach out to me to talk about Repiping .You know, pipes to my house. Like I have no interest in that conversation. If you need to do it, sure.

      Go ahead. Right. It, it’s the same way in delivery, engineering and reaching out to these teams. I don’t know it, my software always continues to deliver.

      It’s fine. Why do I need to care about this? thIs is a very common problem in [00:27:00] platform engineering, but also come from for library producers, API producers, anybody that’s producing something that others are consuming

       you almost always have more interest in in making that happen. Than they do especially when you, the value proposition may be more on one side and the other.

      And that was the key mistake I made. At that time you know, we very much wanted to take the approach of, if we built something really valuable and very interesting for folks they would adopt it. And I think there was merit to that. And so we spent a lot of time thinking about, you know, the early adopters.

      We got some early successes. We got some people to enjoy it. But then we hit that classic crossing the chasm problem where we couldn’t get past the early innovators to the early adopters. And we struggled on that. What was it, was it some combination of features? Was it some combination of capabilities, something that this could do that other things couldn’t? What, what I miscalculated personally was the actual value to the business was the platform engineering side of the, the, the [00:28:00] equation platform engineering needed to see this adopted. Across the fleet for there to be real value. And so given that the strategy may not necessarily be one of slow adoption, but rather it may be more important to take a little bit stronger of, of a, of a, of an approach. And John Kotter talks about this in, in leading he has an article in HBR called Leading Change, but he has a book called, why Transformations Fail. And I will say I read that book during that time and I failed in probably at least the top three even after I read it. So it’s, I will tell you, there is a very, I, I learned how big the gap is between knowledge and wisdom. And, and, and that that gap being how wide experience needs that gap, that that which is experience is that gap, right? And how much of that you actually need. Long story short [00:29:00] you know, managed deliveries, value proposition. Very much is alive, it is moving forward. But that was an experience where I realized because our adoption was very slow, you could imagine that we did not take as an aggressive of an approach, specifically by aggressive, I mean, we didn’t establish a sense of urgency. So teams were necessarily complacent in the adoption. And it’s not no fault to them, that’s the way the culture was designed to operate. But as a result it’s getting adoption, getting that change to actually happen. It was much harder. Now I know that they are doing amazing stuff now over there in terms of, of growing it.

      They, we’ve learned a lot of those lessons and the impact of that approach is really being felt. In fact, years later, I landed at HashiCorp. My peer came from Samsung. Smart Things. He recognized me and said, oh you know, managed delivery. And they apparently larger footprint than Netflix much higher traffic than Netflix.

      All the iot devices right, call into their[00:30:00] and they. Overnight, basically. Maybe it’s not quite overnight, but they, they they fully adopted it and saw some of the benefits of that adoption as a result. And, and and so it was, it was a cathartic to hear or comforting rather to hear. But yes, it was a, it was a good experience in the challenges of change.

      Alexis: Yeah, it’s, it’s very interesting that we are coming, going, going back to that idea of a team owns a problem and now tries to solve it. Unfortunately it’s really a problem for the business, but it’s not necessarily a problem for the other teams. thAt are consuming something from that team. And now how do you create a sense of urgency for the other team when they are not even aware that it’s really a problem for the business and you cannot count on that for them to investigate that part.

      So maybe that it’s other nudge.

      Michael: Well, and I have a, a story about creating the urgency because I, [00:31:00] that’s what one of the things I learned, there’s actually two pieces to that that I learned. And I applied at the next job, actually after I left Hashi after, sorry, after I left Netflix. It was a mid-tier company. We were on a, a, all the entire fleet was on a, a Heroku actually.

      We were hitting problems with that platform. Going back to the ability to introspect and understand how things work, Heroku was too abstract, too high level for us to be able to operate it effectively for the things that we wanted to be able to do. You know, it got us the zero to one, but that, that hard abstraction. mAde a a, it made it impossible for us to get past that one. loNg story short, though, we needed to migrate, we decided the business decided we needed to migrate off. But even with that, we wanna migrate off like all things that happen in a business, they are good goals. They’re, they’re set, like you said, the 24 month goal.

      Oh yes, we should be But how important is that? How urgent is that? I. [00:32:00] This is from my experience with managed delivery, this is what I, I learned. Okay, so two things. One you need a sense of urgency. So how do we create that urgency? You need to get a date set and that date needs to have consequences. So we talked specifically about setting a nine month target from the point that I had started that job and, and the reason for nine months is nine months. Feels close enough that it will happen, but far enough away that virtually no engineering team says no. Right? And, and and I mean this very much affectionately, we all believe that the world is possible in nine months, not three months, but nine months.

      Yes. Nine months. I for sure we’ll have time. So we we got alignment that in nine months we would, we would hit this target. We made sure that the other aspect of this was we were going to shut off Heroku. We were going to actually disable and tear up the contract. And so that was the, the cliff date. [00:33:00] That’s great to have that date. And there’s a lot to unpack on the importance of setting dates, but the other bit that was vital was we needed to get executive, Alignment with that, that needed to be something that the executives would back. And by that I mean you know, the term leadership or executives is, is nebulous just someone in a position of authority at, at the right level that can basically say once you get to that three months away from landing this. That this is a date that will not move. And we, we were able to get that. And those two things ensured that this, that project very ambitious. We moved the entire fleet out and over to Azure, and we had zero service disruption. It was a, it was a remarkable feat. The, the team did an amazing job, but I truly believe having both of those factors Enabled us to do that Herculean task because the last three, three months you can imagine were brutal, stressful[00:34:00] you know we we bought lots of DoorDash for people to, to and, and, you know, and supported them as they were executing on all of this stuff. But once we landed that the entire crew, Could look back and they did and said this was an amazing thing we were able to accomplish, and there was real pride with being able to do it. So very good lessons learned.

      Alexis: I love it. I love it. And once again, that’s, that’s really interesting to, to unpack the learnings about that. Yeah. You need a date and when, when people hear that. They can hear that, yeah, that’s a date, but maybe we can be late and no, that’s really a cliff that’s, there’s nothing behind. And and you need that support, that alignment.

      So nobody will dare to change the date. There’s no option around that. And that’s absolutely clear for everybody. So now they can make plans. They have the time. Nine months is, is is a good one. We were thinking, yeah, it’s feasible. And, and, and I, and then, you know, thing about it, I, I realized that when you [00:35:00] were saying it, that if you would’ve said three months, I would’ve say, oh, no.

      That I would’ve started to think why it was not possible. But nine months I was comfortable to say, yeah, okay. And I know nothing about the challenge, the reality of the challenge. funny. So yeah, you can start making plans. That’s a, that’s a, that’s a.

      Michael: That’s right.

      Alexis: What, what would be your advice to emerging leaders or who want to make a meaningful impact?

      Michael: The first thing I would say is you need to understand your stakeholders. I have learned the enormous value in getting, developing those relationships and deeply understanding who your customers are who your peers are. Who and what leadership is expecting of your organization? A lot of people, I think, focus, especially emerging leaders, they focus on their team and down. I have a lot of experience in [00:36:00] doing that and failing beautifully because I misunderstood what was expected, what was not spoken, but expected by my peers and by upper leadership. And so you really need to understand not just the the surface statements of here’s our goals, here’s our outcomes. What you want to ask is what keeps you up at night You want to ask where things have failed in the past. You want to hear the, the, the reactions. More than you want to hear the thoughtful process of, of desires, right? It’s those emotional reactions, those small perceptions of your team and of what is expected of, of your organization that actually will influence whether or will, will influence whether or not you are. Well, it’ll affect whether or not you are successful because those are the micro perceptions that actually determine whether they are are, they’re going to think of your team as a team to rely upon for those next strategic steps that they want [00:37:00] to take. Right. So understand them very well, and that takes a lot of time, and there’s great books on this. But this is where it truly is around a psych the, the psychological approach far more than it is that technical execution or delivery. The next one is you need to deliver wins within the first 90 days of starting a new job. And there is a great book, first 90 Days. I think it’s a fantastic book on this topic. I Have, I’ve applied it and successfully a few times now. It very much is correct. Get that, get that win. You have to have credibility when you go into a room. You have to be able to be believed when you say we should do X or Y. Otherwise, you’re gonna stay in the tactical level always because you haven’t established that you can actually solve bigger problems. The key thing with getting that credibility in the first 90 days is you don’t need a big win. You just need something meaningful, something that addresses a concern. Peers of mine had actually mentioned this to me years before too. Don’t [00:38:00] try to run after. The biggest thing you can run after, especially when you first start, start with something. yoU, you, you can own and influence, so it’s something within your control. Don’t do something that’s gonna require a bunch of other folks to be aligned, especially when you first start. It’s challenging to do that, so it should be something for the most part, you can control. I. Second part, it’s gotta be something that matters to other people.

      It doesn’t really matter what it is. It doesn’t have to be a technical solution. It could be an organizational solution. It could be an information solution. It could be a communication solution. It could be any of these things, but it needs to be something that actually addresses a, a, a fear or concern. A great example of this is just starting a monthly newsletter for your organization and ensuring the rest of the business understands even what your team does or your group does. That’s surprisingly a big problem in many places is just the awareness factor, and doing that suddenly puts you on the radar of a lot of people, and it can really, it can really move things forward.

      That’s not a technical problem at all,

      Alexis: Yeah.

      Michael: but it is a problem and it can establish you. [00:39:00] The third thing that emerging leaders need to be taking a look at to have real meaningful impact, define The purpose for your team. And by that I mean you need to bring your team into that. But defining a purpose is one of the most fundamentally powerful actions that I have ever learned to take with my team.

      And purpose is different from mission and vision. a Purpose is. It is the, it lives the lifetime of that team or that group that you are managing. And a purpose is not it, it sometimes it’s referred to as a North star. I don’t think it’s quite that. It’s not quite that right way of seeing it. A purpose.

      This establishes a philosophy that everything stems from. So one of my favorite examples of this was I think he was a, gosh, and the name is gonna slip outta my mind, but he was a, a French designer actually, I think that helped establish the purpose for Disneyland and that purpose was to create happiness in the visitors. Now, if you think about that, that sounds very simple, [00:40:00] but it’s a very powerful fulcrum. Because at that point, when you have that, everything from how you name the parking lots, you name them after Mickey and Goofy, not A and B and C, the design of the trash cans, the uniforms, the decision to have very pleasing flower beds that are millions and millions of dollars of investment for each of these things. Why do you do that? Because each of these pieces maybe make somebody smile a little bit more. Establishing a purpose for your organization enables you to prioritize. It gives your teams freedom to execute and to think more broadly and it enables you to align with what your next strategic steps need to be. It it really is the guiding, you can think of it as a guiding principle. So there’s, I, I’ve written articles on this and, but there’s much better, smarter minds than mine that have, have spoken on this

      Alexis: Ah, I will link to that and we will let people [00:41:00] people decide. About that . So what, what’s next for you? Any exciting projects or initiatives you, you, you want to share?

      Michael: Yeah, so well with Hashi Corp I think one of the exciting things that we have coming up next from the platform engineering organization is really trying to crack this self-service nut. You know, Hashi Corp is an organization that has, we we build tools for infrastructure management, right?

      I mean, we build tools for platform engineering. How do we, how do we leverage all of the, the tools that we have and the patterns and behaviors that we wanna encourage to enable self-service within our organization? So a team being able to go from zero to one. I know this is a nut that a lot of people have cracked in the sense of they’ve created, you know, IDPs, right?

      In, in internal developer platforms. But I think that that’s more of a, a, a how, and I think I wanna get back to again, the principles. What should that, what, what are we caring about enabling the actual day One [00:42:00] problem of give me a service is not a hard problem to solve. It’s been solved a lot. The day two problem of now I wanna add a database to my service. That’s a harder problem. And that’s one of the ones I’m excited to see get moved forward. Yeah, so that’s, that’s, I’m looking forward to that next

      Alexis: That’s very cool. So let’s talk again. Thank you very much Michael for joining. have fun solving that.

      Michael: Thank you, Alexis. 

    • Crafting Compelling Investor Update Emails: A Guide for Startup Founders

      Crafting Compelling Investor Update Emails: A Guide for Startup Founders

      Introduction

      Effective communication with investors is a cornerstone of successful startup management. A well-crafted investor update does more than report facts; it actively engages your backers in your journey. This guide explores how to structure updates that not only inform but also encourage active participation and acknowledgment of investors’ contributions.

      The Structure of an Effective Investor Update Email

      1. Greeting and Positive Opening

      Start with a personalized and upbeat opening to engage your investors from the outset.

      Example: “Hello Investors! As we embark on a new and exciting year, I’m thrilled to share our latest milestones and plans.”

      My example could be even better with: “Hello Alexis!” as I am more tempted to read when my first name is mentioned.

      2. Highlight Major Achievements

      Begin with key successes to demonstrate the positive impact of your investors’ support.

      Example: “This quarter, we’ve exceeded our targets, achieving record-breaking performance!”

      3. Key Metrics and Financial Performance

      Detail the financials and growth metrics to provide a clear picture of the company’s health.

      Example: “Our revenue surged to $X00,000 in Q4, marking a significant X0% growth from the previous quarter.”

      4. Operational Updates

      Share important updates regarding team expansions, strategic shifts, or infrastructure enhancements.

      Example: “We’re excited to welcome our new CTO, John Smith, who brings a wealth of experience to our tech team.”

      5. Challenges and Lowlights

      Be transparent about challenges, fostering an environment of trust and collaboration.

      Example: “We’re facing some challenges in optimizing our supply chain, which we’re actively addressing.”

      6. Product Updates

      Update on product developments, customer feedback, and market positioning.

      Example: “Our latest product iteration has been well-received, with significant improvements based on customer insights.”

      7. Future Plans and Goals

      Articulate your vision and objectives for the upcoming period.

      Example: “Looking ahead, our focus will be on scaling operations…”

      8. Engagement and Calls to Action

      This is crucial. Make specific requests of your investors, and include at least three actionable items, varying in commitment level. This approach increases the likelihood of engagement.

      Example: “To continue our momentum, we need your involvement. Here are three ways you can help: 1) Try our latest product and provide feedback, 2) Introduce us to potential partners in the XYZ industry, and 3) Share our recent press release in your network. Any of these actions would be immensely valuable.”

      9. Recognition of Contributors

      Acknowledge and thank investors who have made significant contributions. This not only shows gratitude but also motivates others to contribute.

      Example: “A special thanks to Jane Doe for her invaluable marketing insights, and to John Doe for facilitating key industry introductions last quarter. Your contributions have been pivotal to our success.”

      10. Closing and Appreciation

      Conclude with a sincere note of thanks, reinforcing the importance of their support.

      Example: “Your belief in our mission continues to be our driving force. Thank you for being with us on this exciting journey.”

      Conclusion

      An investor update is a strategic tool that goes beyond mere reporting – it’s about creating a collaborative and engaged investor community. By clearly articulating both the achievements and challenges, and by inviting specific actions and recognizing contributions, you foster a deeper connection with your investors. This not only keeps them informed but also actively involved in your startup’s journey towards success.