Tag: open source

  • 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] 

  • How the Cloud Threatens Open Source and what we can do about it: A Conversation with Daniel Riek

    How the Cloud Threatens Open Source and what we can do about it: A Conversation with Daniel Riek

    Open source is everywhere. It powers the cloud. It powers our phones. It powers most of the modern software stack.

    So why does it feel like we are losing control?

    In this episode, I’m joined by Daniel Riek, who works on special projects and strategy with the CTO at Red Hat. Daniel has spent most of his career in the open source space, from startups to large scale product leadership, and he brings a sharp perspective on what changes when open source meets the cloud.

    Open source is about freedom and sovereignty

    Daniel prefers the term free software: not free as in cost, but free as in freedom.

    Freedom to understand how software works, change it, improve it, redistribute it, and collaborate. In other words, sovereignty: the ability to control the technology that increasingly defines our lives.

    And that is not a niche concern anymore.

    Software is embedded in the physical world: connected devices, home automation, infrastructure, products, services, everything. As software becomes more central, the question becomes simple: who controls it?

    The cloud is a powerful paradigm

    Daniel defines the cloud as more than infrastructure. It is a paradigm built around three promises:

    • Developer velocity: teams can keep building without stopping for underlying dependencies
    • Operational excellence: best practices are embedded so systems stay reliable
    • Elasticity: you scale up and down dynamically and pay for what you use

    From the outside, it looks perfect.

    So why does it create a threat for open source?

    The core tension: open code, closed operations

    The cloud is built on open source. Linux, Kubernetes, containers, virtualization, databases, libraries: open source is the foundation.

    But the differentiator in the cloud is not only the code.

    The differentiator is how you run it.

    Operationalizing software at scale requires know how: security, reliability, performance, upgrades, incident response, compliance, cost controls. Cloud providers turn that expertise into a proprietary advantage.

    That is the turning point.

    You can have open source software, but if you cannot operate it at the same level, your freedom becomes theoretical. The control shifts from the code to the service.

    The same pattern shows up in everyday life. Many people do not run their own mail servers anymore because operating them securely is too complex. A small inconvenience is often a symptom of a bigger shift: the operational layer becomes the lock in layer.

    Abstraction on abstraction and the distance from the underlying system

    Cloud native development encourages abstraction. You do not want every team, or every project, to reinvent databases, messaging, identity, security, and operational tooling.

    So abstractions pile up. Abstraction on abstraction on abstraction.

    The benefit is speed.

    The cost is distance:

    • distance from what is running
    • distance from how it is configured
    • distance from how it is secured
    • distance from how to debug it when it fails

    And when those abstractions are proprietary services, the distance becomes dependency.

    The downward spiral: open source built on proprietary foundations

    Daniel makes a strong point: the cloud era can push open source into a downward spiral.

    Open source projects want to focus on their core mission, not on running everything underneath. But if the operational layer is proprietary, projects face a dilemma:

    • depend on proprietary black box services, undermining sovereignty
    • or run everything themselves, which creates a disadvantage in speed and effort

    Daniel uses GitHub as a revealing example.

    Git is open source. GitHub is a service built on top of Git. The glue, integrations, and differentiators are proprietary. Many open source projects depend on it for collaboration, issues, CI, and now AI assisted workflows.

    That does not make GitHub “bad”. It makes it a clear illustration of dependency in the cloud era.

    What we can do: expand open source to include operation

    Daniel’s proposal is direct:

    Open source must expand beyond “code in a repository” to include operationalizing the code.

    That means:

    • making “running it” part of the project’s scope, not an afterthought
    • enabling others to build on services, not only on libraries
    • creating a virtuous cycle of contribution at the service level, not only at the code level

    Not every project will do this the same way. But the direction matters.

    Decentralization as a counterweight

    The cloud tends to centralize. Centralization increases dependency. Dependency increases power concentration.

    So Daniel highlights decentralization as a key counterweight.

    He points to Mastodon as an example: open source software, with a federated model where many instances can exist and interoperate. The project includes operation as part of its reality, not only as code.

    The broader lesson is not “everyone should use Mastodon”. The lesson is that decentralization is a viable pattern when centralized platforms become too controlling.

    The leadership skills the cloud era demands

    Daniel is careful here: some of this is prediction, not finished history.

    But the direction is clear. Open source in the cloud era requires leaders who can:

    • understand dependencies and their long term cost
    • reason about centralization versus decentralization
    • think in terms of sovereignty, control, and sustainability
    • distinguish software, product, and service
    • align principles with strategy, not convenience alone

    There is also a more personal layer: conviction.

    Where do you keep your principles even when convenience pulls the other way? Where is the line? What tradeoffs are you willing to accept, and which ones create unacceptable dependency?

    A moving landscape, not a fixed answer

    Daniel ends with a reminder: the tech industry moves in cycles. Centralization and decentralization swing like a pendulum. Costs, crises, and new constraints reshape decisions. Edge computing is one example of a decentralizing force driven by physics, latency, and reality.

    Leadership means staying aware, staying honest, and making choices that mix strategy, principles, and immediate needs.

    Listen to the episode:

    You can listen to this episode on your favorite platform: Anchor, Spotify, Breaker, Google, Apple

    Here is the transcript of the episode:

    00:00.00

    Alexis Monville

    Welcome to the podcast on emerging leadership. I’m Alexis Monville. Today we are joined by Daniel Riek, who works on special projects and strategy at Red Hat. His previous roles include leading Red Hat’s AI Center of Excellence, managing cross-product integration engineering, leading Red Hat Enterprise Linux Product Management, and multiple startups, including ID-Pro, one of Europe’s first open-source service providers. Daniel has spent most of his career in the open-source space, and today we will discuss the future of open source in the cloud era and how individuals and leaders can support open source and ensure that it remains accessible and open. For those who may not be familiar with the term, Daniel, could you explain what open source is and why it’s important?

    00:54.35

    Daniel Riek

    Of course. I actually prefer the term “free software,” which is not about free as in no cost. It’s about free as in freedom. Free software allows you to change the software, understand how it works, improve it, and redistribute changed versions of the software. “Open source” is basically just a marketing term for the same thing. Often we refer to free and open-source software (FOSS) to combine them. I use them largely synonymously. The point is that it’s about empowering the people who use software and giving them the right to understand the software, adapt it to their needs, improve it, redistribute, and collaborate on the software. It’s really about sovereignty in technology. It’s about controlling the technology that defines your life.

    01:56.11

    Alexis Monville

    Okay, really interesting. In a very interesting talk at FOSDEM, you’ve spoken about the challenges facing open source in the Cloud Era. Could you tell us more about these challenges and why they are important for those in the tech industry to be aware of? Why should people outside of the tech industry care?

    02:19.16

    Daniel Riek

    Right. Free software is about empowering you to control the technology. As everyone is probably aware, more and more of our life is defined by software. An example I often use is a connected mousetrap I have in my basement, which does a very traditional task. It’s a mousetrap, but now it’s connected to the internet. It talks to my local Wi-Fi network and then talks to a cloud server and then notifies an app on my phone when it did what it does, which has a huge advantage. It avoids me finding things weeks later in the basement, so it’s really useful, and I bought that mousetrap, which is a very physical, very mechanical thing, because of that software feature. My light switches in my house are all small microcontrollers. They’re all small computers running software and talk to each other and, through some home automation, talk to the internet. So everything in our world is defined by software. Basically, everyone is exposed to that to some degree. Every business is definitely exposed to that, and more and more businesses differentiate through software features in their internal organization, in their customer interactions, and progressively even in their product. So everything is software, and logic is done in software. Our interactions with the world are with software. Because we control our physical world with software, the software complexity is approaching the complexity of the physical world. It’s no surprise there.

    04:24.70

    Daniel Riek

    And part of that of course is that things need to be always connected it means that there’s more and more software and a paradigm that really came along with that expansion and you can argue about cause and effect. But, you know, I think they just co-evolved is the concept of Cloud computing which I would define as the mixture of an operational paradigm – how do you run your software – and the underlying Infrastructure. That’s optimized for developer velocity so you can keep building software without having to stop for things that are underlying dependencies, whether that is infrastructure like a computer you need to run on, a network connection or a service like a database. You compose your software and you try not to stop for underlying infrastructure or have your developers stop for underlying infrastructure, so developer velocities. The second part is operational excellence. You want because if your business or your world or your house depends on software running, you don’t want to have any kind of operational fragility. You want your software always to run and you want the best practices that are common in whatever one does. You want that to be applied to how your software runs. Because if, even if you cannot have a positive differentiation from optimizing things because you’re just doing something that’s very mundane like running a web service or something, you still would have a disadvantage if you weren’t doing it as well as your competitor, right? So you want the operational excellence, the best practices embedded in how your stuff is run, how your underlying services and infrastructure is run, and lastly, you want elasticity which means that you can increase or decrease your usage dynamically at any time. So if you have, for example, a sale, a new product launch, and you expect a lot of traffic, you want the ability of your services to scale up, and then when you don’t need that anymore, you don’t want to keep paying for services you don’t need anymore. That’s what we call elasticity, so things can grow and can reduce as needed. And that is really what Cloud is about. It’s a paradigm that gives you a software architecture and infrastructure that supports maximizing developer velocity so you never have to stop when you create your own stuff. It embeds the operational excellence best practices, and it’s elastic. And yeah, most people know someone like Amazon or Google or Microsoft or in Asia, Alibaba, and you know there are big cloud vendors, IBM is a cloud vendor, Oracle is a cloud vendor, so these are companies that provide that kind of infrastructure, and there are many smaller ones. Even people running their own data center want to run them in this paradigm. So the goal is to support modern software and your dependencies by running yourself in the cloud paradigm.

    07:56.46

    Alexis Monville

    Yeah, so Daniel, if everything around us is defined by software, and we have that great capability of the cloud that is, as you said, optimized for developer velocity, we have operational excellence so things can continue to run always, and we have elasticity, so we don’t pay for what we don’t need, so we pay only for what we need, and we can increase our capacity. That’s absolutely perfect. So why are there challenges for open source?

    08:27.14

    Daniel Riek

    Yeah, that’s really interesting. So first of all, everything that people do in the cloud nowadays is built on top of open source. All the major clouds use open source. They’re usually based on Linux as the operating system. Open source virtualization technology that’s in Linux like KVM, or container concepts like Podman and Docker, and orchestration tools like Kubernetes. So, it’s a lot of open source in there. The place where open source is successful right now is the common base of what I call “code assets” – software program code that sits in a repository or is a binary that you can take and run when you need it, and that’s what most of the cloud vendors use. It’s what the cloud services are built on the highest. So, if you have a database in there, that has usually for most, a strong open source base. Even most of what any user does nowadays is built on the foundation of open source code. People build their own business differentiation in software. For example, let’s stick with the example if I build this control stack for my connected mousetrap, right? There’s a lot of open source in there, both on the device itself, some of the pieces in the microcontroller, our open source libraries. You can basically assume that because it’s most of the common underlying software, the middleware that they use to talk through the internet is based on open source. The parts on your mobile phone also include open source libraries, and you can verify that if you go to your mobile phone settings, you will find somewhere the open-source licenses that they have to list.

    Now, the issue is that when you operationalize software, and in fact, operationalizing open source software, is the biggest differentiator for any kind of cloud vendor or people who provide software as a service. Even in some cases, they take the same open source code that’s publicly available, but they know how to run it with that operational excellence, and that becomes suddenly a proprietary differentiator. It includes knowing how to make it scale, how to run it, how to configure it securely, and how to keep it secure against attacks, which is a common problem. Software gets attacked directly or through supply chain issues, and if you don’t have the right process in place, and you download random open source software from the internet, there’s a risk in that. So, the cloud providers have these processes nailed down, and taking open source software and actually running it as cloud-grade enterprise-grade software is suddenly a proprietary thing. That obviously creates a conflict because now the point of open-source software of “I want to empower people to be in control of their technology, I want to provide freedom” is running up against the problem of actually running the software now being a proprietary feature.

    12:20.95

    Alexis Monville

    Okay, so the point of open source was that freedom and that control and if you have a software that is open source, but if you don’t know how it’s run, then you don’t have that freedom and you don’t have that control anymore. So that’s the problem. So what can you do about it?

    12:40.66

    Daniel Riek

    So that’s the first problem. There’s another problem that is kind of a second-degree problem, but I want to mention it. The first one becomes very obvious as soon as you try to do this. It’s a common discussion in the open-source industry or business. Even people who do a lot of open source, for example, don’t run their own mail servers anymore because of the complexities of running it securely, keeping it operational, protecting it. Or even being able to get your mail accepted by other services, the way to use it is not as free as the underlying code anymore. That becomes pretty obvious that, “oh, I have this open-source software, but I don’t know how to run it or at least not as securely as you know at that scale or as well as performant as efficiently.” But the other problem then compounds that because, if you do cloud-native development right, the point is of cloud is to abstract from underlying complexity, so you can focus on the core way you want to differentiate. If you’re a business, you want to implement your business differentiation in software and all the things that are not differentiating for you that are just the requirements that you have that you know like a database. Most businesses just need the database, and having a better database probably is not going to help you sell more of your product in most cases, right? So, you want to focus on your application that uses the database. You don’t want to spend your time on figuring out how to run the database. The same is true for an open-source project. If I’m doing an open-source project, I want to focus on the core of my project. Let’s say it’s Home Assistant, home automation software. I want to focus on making that better, not on how to run the underlying database or message bus or whatnot. So, what happens is that people start building abstractions on top of abstractions on top of abstractions, and that creates a distance from the underlying open-source software.

    14:08.24

    Alexis Monville

    Yeah, that’s why I gave up on running my own mail server when all my emails were going nowhere. I gave up and used the service, and then some of them were finally reaching their destination.

    14:18.80

    Daniel Riek

    Right, exactly. And that sounds like a small problem, but it’s a symptom of the bigger problem, which is really that people are building abstractions on top of abstractions on top of abstractions, and they start to lose sight of the underlying open-source software. So, it becomes really hard to know what is running where, how it’s configured, and how it’s secured. And when something goes wrong, it’s really hard to debug because there are so many layers of abstractions that could be the problem. So, that’s really the second-degree problem.

    15:40.35:

    Daniel Riek

    I want to figure out how to do the best home automation. I don’t want to have to figure out how to run the underlying service to provide that. And because those services in the cloud are run as a proprietary concept, you, as an open source project, have two choices: either you start depending on proprietary black box services that you can’t look into and you can’t control, or you have to run all of it on your own. And that creates a fundamental disadvantage for open source projects when they try to develop in a cloud-native way. It means they benefit from all the greatness of the cloud paradigm, where they either have to do it themselves and figure out the operational excellence or depend on a proprietary service, and thereby undermine the whole point of open source even when they create code. And that creates a downward spiral of open source value when open source development itself starts depending on proprietary approaches. A great example here is GitHub, right? Most open source projects use GitHub, which is an awesome service that gives you management for your source code, collaboration issue management, CI management, more and more integrations, now an AI bot that helps you write code. It’s built on open source software, right? It’s in the name. Git is an open source project created by Linus Torvalds, the same person who created Linux. But the service itself, the glue code, all the differentiation, everything that makes it such a great tool other than the core open source code underneath Git, everything else is proprietary. So the moment you use GitHub, you have built this kind of proprietary dependency in any open source code. And it’s not just GitHub; it’s actually owned by Microsoft, so for people who have a long history in open source, Microsoft was always anti-open source. They called open source a cancer back in the day, and they were very anti-open source. Now, most open source projects, at least in their ongoing practice, depend on the Microsoft service to keep building and managing their source code.

    18:18.30

    Alexis Monville

    Yeah, Dependency is an interesting challenge for open source. So if we want to escape that downward spiral that you mentioned, what can we do about it?

    18:32.46

    Daniel Riek

    So ultimately, on a high level, I think that open source needs to expand the concept of open source from code – you know, code in a repository and the code license – to include operationalizing the code. That means two things, right? One is like, and it’s not going to be the same for every open source project, but ultimately, open source projects should include in the project charter running their software as a service or as part of a service. And with the goal to enable other open source projects to then build on that service in a cloud-native model so that you create the same kind of development approach that you have in the proprietary world, where people can aggregate existing services and come together and create this you know, it creates an exponential growth rate, right? Because you can build on top of all the things that other people have done which in open source, you do that kind of at the code level, you reuse libraries. But if applicable, I should be able to reuse an existing service and then create a virtuous cycle of open source. It’s what we call this contribution cycle where people come together and contribute to open source projects to bring them forward to expand that to a similar cloud-native concept of things running and then other things aggregating beyond just the code in a repository.

    20:13.76

    Alexis Monville

    Wow, okay, what’s the first step to do that?

    20:17.17

    Daniel Riek

    I think that depends a little bit. There are different approaches for different projects that will be taken, and there are a bunch of ongoing things. I think one key point is starting with awareness right? We need open source projects to be aware of the problems, aware of the dependencies. I think we need to get a push towards decentralization, and that’s an interesting topic, right? Part of the problem, part of the benefit of the cloud that how people consume it today kind of co-evolves with increasing centralization. So people move to the same thing, which is part, like, it increases the benefit for keeping things proprietary for that centralized entity, and increases these dependencies on very few entities. So a decentralized approach automatically counters that, and we’ve seen that in a different space, right? Like if you look at the Twitter situation, a lot of people have decided that Twitter, for this or that reason, isn’t a great platform anymore. It’s too centralized, and many people don’t agree with the approach of the previous or current ownership, and whatever. I don’t want to get into that issue. The structure is the point though, is people have a problem with this one centralized platform being the one place where everyone comes together, having to submit to their rules, and not being able to have sovereignty over your own content. And the answer that kind of is a front answer right now interesting is a project called Mastodon, which is an open source project with a decentralized approach, right? Where everyone can run their own social media instance of Mastodon. It is the true open source project. It already has this concept of running it as part of the project, and there are many people, you know? So, it’s not just code in a repository, the people involved in the project themselves are also running instances of it, and everyone can go and run it. It’s easy to run because it’s part of the project. And then you just connect, you negotiate with others to connect to them so you create a decentralized social network of people running their own instances of Mastodon. So that’s a great example of an open source project that has cloud-native operationization as part of the content. I’m sure it could be improved but it you know it obviously is working to some degree because a lot of people are now using Mastodon, and it’s evolving fast to be an alternative to centralized social media platforms.

    23:19.10

    Daniel Riek

    So that’s a great example, right? It comes down to expanding the project scope to include operationalizing, so running the software as a service, and a decentralized approach, which means that many people can run it and you somehow bring that together to create a joint benefit and growth and collaboration on top of that.

    23:44.79

    Alexis Monville

    So awareness of dependencies, running your project as a service, and thinking of decentralization. So avoid that effect of centralization that will put you in that trap of building things proprietary. Okay, that sounds like something people can do. The question would be, next, why they are not all doing it, but Mastodon is a good example. So, let’s go with that. What are, from your perspective, the key leadership traits and skills needed to succeed in open source in that cloud era and to make that happen?

    24:31.19

    Daniel Riek

    That’s a hard one, right? Because now I’m looking at a crystal ball, and it’s very much like it’s my opinion, not an experience because it’s an ongoing struggle, and you know, it’s generating like open source as a concept for code at rest has one, right? It’s the standard base for everything. So it’s in it has proven that it’s the most efficient way of creating and maintaining the underlying common code that everyone needs but that no one can actually differentiate on. And we all have also proven that you can professionalize that and create businesses around that without compromising the underlying concept. I work at Red Hat as you know, and with me and that’s what Red Hat does. Red Hat has a subscription business model that is fully compliant with the concept of open source. Ultimately, selling the similar to how cloud is kind of about the embedded best practices. Red Hat’s business model is the best practice of maintaining enterprise-grade open source and increasing cloud-grade open source code for business users. A huge benefit for everyone, right? It benefits everyone because it’s complying with the open source model and contributing back. It is also collaborative with everyone else in the space, usually. Reddit does not solve problems on its own. It’s always in collaboration, even with competitors because it’s this common underlying base, right? So that works really well, and that’s proven, call it: The normative power of the factual that is working in the software industry.

    26:35.12

    Daniel Riek

    And, you know, that doesn’t mean that there is no proprietary software, but that’s usually kind of close to the customer use case, you know. Ultimately, what customers implement themselves usually, they keep proprietary because that’s their business differentiation. But soon as you get like one or two levels down, you get into common services. And I think, to my predictions, that model can be expanded to services right with a decentralized approach. And I think a key leadership really like it’s understanding the benefit of open source and ultimately like, I have kind of two minds there, right? But in my private life, it’s something like a conviction that I want to be in charge of my own technology. And I want to be, so I use open source even when it’s not necessarily convenient, right? That if you go into the business side, I have a more utilitarian view on that, right? I want to do open source so it benefits me. And I think, so I think not going to be sustainable, so you have to find a synergy where open source is really useful for you, which aspects of it are critical for you, think strategically, think about your dependencies, and how you want to have control and sustainability and sovereignty so that you don’t get into dependencies that harm your business. Then, focus on those areas. I think that is the key leadership skill that people need to develop, but it’s not the same for traditional open source for code at rest. It’s just about adapting it to not accept, for example, for cloud services, the things that you wouldn’t accept for code at rest.

    28:54.20

    Alexis Monville

    I like what you said about conviction, and some people are saying you don’t want to leave your principles behind for convenience reasons. But the line is probably blurry and there’s probably a limit that you cannot overpass and that’s interesting to be aware of that too.

    29:23.62

    Daniel Riek

    And yeah, and I mean, we always, if you look at the cycles in the tech industry, it’s always a little bit of pendulum swinging back and forth between concepts, right? You always have, for example, a trend to centralization, like the mainframe. Then we had the PC, then we got the cloud, which turned back into centralization. Some people say it’s just a reinvention of the mainframe, right? Like it’s a black box service running on someone else’s leased hardware that you pay by the hour. It’s really convenient, and I use it for certain things. I use traditional data center approaches for other things still, but in the cloud-native mindset. But sometimes it’s better to buy the hardware and not run pay by the hour because you’re always utilizing it. So you have to, and I think we see right now, we had a huge expansion, there is an economic crisis going on, and we see a lot of people reconsidering that, going into cost control mode and suddenly reducing their cloud spend or even rediscovering their data center. We have other trends like edge, which comes from software defining the world. Now software needs to move closer to the data sources and interaction points. The classic example is a self-driving car. A self-driving car needs to take decisions locally because if it has to ask the cloud, it will fail to brake in time. So it has to take the decision locally, so you need local compute power. So suddenly, you need a decentralized approach there, and so it comes back to leadership, looking at the trends and the requirements honestly, reconsidering decisions, reconsidering the trends, and making your own choices informed by a mix of strategy and principles and immediate needs.

    31:38.37

    Alexis Monville

    And among those are an understanding of dependencies, an understanding of centralization, decentralization, and that understanding of the difference between software or product and the service itself. It’s really fantastic, Daniel. Thank you so much for joining us today and sharing your insights on the future of free and open-source software on the cloud. Your experience and expertise in this field are truly valuable and inspiring to emerging leaders in the tech industry and everywhere else. Thank you, Daniel.

    32:18.59

    Daniel Riek

    Thank you, Alexis.

    Photo by Taylor Van Riper / Unsplash

  • Emile wants to solve consistency the open source way

    Emile wants to solve consistency the open source way

    Do you remember Igraine from the Primary Team story? Igraine leads the EMEA region of a global company. Bob, Igraine’s manager, told the Field Leadership Team that he wanted to get more consistency from the three main regions and that Igraine, leading EMEA, Yun, leading APAC, and Aileen, leading Americas, should come up with proposals. Bob wants to drive more consistency to scale the business and avoid duplicating efforts in the three regions.

    At this point of the story, Igraine invited Emile, the consultant passionate about Leadership and Organizational Development, to discuss how to solve the challenge. Emile built a rapport with Igraine when he dared to discuss the Tribal Leadership stages with her. Find more about that in Are you at the right table?

    Emile is super excited about the opportunity. He heard noises from the grapevines that the pendulum was about to swing from decentralization to centralization. Some even say that there will be complete top-down control from the global organization over the regions.

    Emile has another idea in mind to solve the consistency and duplication of efforts issues. He reached out to Veronica, the head of the Sales Operations team in EMEA, to get a sense of the concrete problems and evaluate his idea.

    As the three regions grew independently, they put processes and tools to support their sales team. The global team at that time has no interest in standardization and was ready to invest in more people to solve the reporting issues caused by the inconsistency between the regions.

    How to solve that?

    Emile wants to solve consistency and duplication of efforts in the open source way.

    The open-source model is a decentralized software development model that encourages open collaboration, meaning “any system of innovation or production that relies on goal-oriented yet loosely coordinated participants who interact to create a product (or service) of economic value, which they make available to contributors and noncontributors alike.”

    Levine, Sheen S.; Prietula, M. J. (2013). “Open Collaboration for Innovation: Principles and Performance” Organization Science.

    Emile proposes to identify the top 3 processes that are the most time-consuming for the teams. And then, Emile offers to engage the three regions in staffing cross-functional teams with people from the three regions to make the processes consistent and select the tooling. Veronica is onboard with the idea! She is ready to join forces with Emile to convince others that the open source way will be better than centralization like for software development.

    Emile imagines that with three successes, they will select the next three and even have a more open approach to get people to volunteer to contribute to the selection and the resolution of the next challenges.

    When Veronica and Emile go to Heiden, who leads the finances team for EMEA, he took a good 30 minutes to poke the holes in the approach.

    After that, he pauses and laughs. Veronica and Emile are puzzled.

    Heiden, just says: “okay, you are really serious about it, and I agree that we should try.” He then continues waving the book Humanocracy in front of the webcam: “Like Gary Hamel and Michele Zanini said in the book, central planning, and central control is the model of the old USSR, not the model an innovative company should embrace, right?”

    Let’s propose the open source way!

  • The Myth of 10x Engineers: Growing Beyond Technical Skills

    The Myth of 10x Engineers: Growing Beyond Technical Skills

    The idea of the “10x engineer” has been around for decades. It suggests that some engineers are inherently more productive, more impactful, or more valuable than others.

    But is that really the right way to think about excellence in software development?

    In this episode of Le Podcast on Emerging Leadership, I had the pleasure of welcoming Julien Danjou, an open source software hacker with more than 20 years of experience and the author of several books on Python.

    Questioning the 10x engineer myth

    I invited Julien to discuss the myth of 10x engineers and to share his perspective on how engineers actually grow their skills and impact over time.

    Very quickly, the conversation moved beyond code.

    According to Julien, while technical skills are important, two other dimensions are essential:

    • understanding the business, and
    • understanding the social component of work.

    Beyond technical excellence

    Great engineers do more than write efficient code.

    They:

    • understand the context in which their work creates value
    • communicate effectively with others
    • collaborate across roles and disciplines
    • and take responsibility for outcomes, not just tasks

    These capabilities multiply impact far more reliably than individual technical speed.

    Examples you can apply immediately

    One of the strengths of this conversation is how concrete it is. Julien shares examples drawn from real experience, all of which can be applied immediately by engineers who want to grow.

    The discussion resonated strongly with me and aligns closely with the ideas Michael and I share in our book I am a Software Engineer and I am in Charge.

    Further references

    You can find more about Julien and his work here:

    A final thought

    If you are an engineer looking to grow, or a leader wondering how to support excellence without relying on hero myths, this episode offers a grounded and practical perspective.

    The real multiplier is not being 10x faster, but being 10x more connected to people, context, and purpose.

    Le Podcast – Season Two

    Le Podcast – Season One

  • Contribute to the Success of OpenStack

    Contribute to the Success of OpenStack

    During the OpenStack Summit in Austin, Mark McLoughlin and I delivered a talk titled: “Contribute to the Success of OpenStack”.

    Our talk was meant to explain how we were inspired by agile values and principles to improve our internal organization, and how we thought it could impact our ability to contribute more effectively to the OpenStack project.

    One of the idea that is often used to describe the way companies are contributing to open source project is that you need at some point to wear your company hat to represent what your company needs, and some times you need to wear your upstream hat to represent what the project needs. We speak some time of the need to balance between upstream and downstream.

    Our point was to say that this idea represents the reality perfectly well in projects were the developers are the users of the projects. In this case they are solving problems they are facing on a regular basis.

    The OpenStack project is more complex in this sense that the developers are rarely the main users of the project. They don’t have to operate a large scale cloud on a day to day basis.

    So, to be able to understand the needs, and to propose effective solutions, the developers of the project need to hear from the real users. That’s were they need to wear at the same time their corporate and upstream hats, because the customers and partners of their company represents the needs of the real users, and wearing those hats they are bringing a lot of value to the project by proxying the real users.

    We also explored the fact that when the reaction toward one of the idea that we were bringing on the table was really hostile, there was probably good reason for that, and that was great value for our company that the project was bringing to us. This obvioulsy can only be achieved when the maturity of the project is high enough, especially on the corporate diversity aspect.

    We covered after that how we were organizing the teams that are contributing to OpenStack by giving them a clear focus to solve some real user’s needs, and end to end responibility to solve this. Those teams are primary responsible for contributing to some of the components, but the components are not driving the structure of the organization.

    For each team, we want the team members to understand their mission, their goals, and to drive their contribution in the value flow.

    Here is the recording of the session:

     

    For the next Summit in Barcelona, I proposed 3 talks:

    • The first one with Maria Bracho: “Providing Tooling for Effective Collaboration”
    • The second one with Nick Barcet: “Does your voice count in OpenStack? Yes!” this one could be consider as a followup of the talk given this spring
    • The third one: “Raising the awareness on diversity”, one workshop during the last summit was an eye opener for me, and I would like to continue the effort to raise the awarness on that topic.

    You can vote on your preferred presentation here: https://www.openstack.org/summit/barcelona-2016/vote-for-speakers

    If you want to vote for the one I submitted search  for my name: monville 🙂

    Thanks!

     

    Header photo by William White

  • What science knows about happiness that could tranform OpenStack

    What science knows about happiness that could tranform OpenStack

    A short article to publish the video recording and the slides of the talk I gave today at the OpenStack summit in Austin.

     

     

    Header picture is from Ryan McGuire.

  • We trust you

    We trust you

    During Red Hat Summit in Boston this week, a documentary video was showed during the keynote sessions. This video describes the way Penn Manor school district used open source in their education project.

    Charlie Reisinger is the IT director that lead this openness strategy, also delivered a TEDxTalk in Lancaster to tell the story.

    I hope this can inspire a lot of schools to give their trust to the students and help them to develop their self-esteem and self-confidence.

    More details here: http://summitblog.redhat.com/2015/06/24/open-source-stories-penn-manor-the-power-of-open-in-education/

  • Bridges and Hierarchy

    Bridges and Hierarchy

    Mark McLoughlin delivered the Red Hat Keynote, on the morning of the second day of the Openstack Summit in Vancouver.

    During the afternoon, he delivered a more intimate talk about the governance of the Openstack project.
    The main idea is that, the new Big Tent organization model will allow the emergence of new projects, and it can be the time to redefine the main values that will help the project contributors to take the good decisions.

    Mark started his talk refering to the Keynote Eben Moglen gave in Auckland at LCA 2015. In this keynote, Eben Moglen explained that the hierarchical organization model that we all know very well, is the model of the 20th century, and that the organization of the 21st century will be based on transparency, participation and non-hierarchical collaboration, like it is in free software.

    Mark continued his introduction with a reference to Andy Hunt’s blog post, The Failure of Agile. Andy Hunt is one of the original writer of the agile manifesto, so when it came to discuss agile, we can at least consider him seriously. The main point of this article is that a lot of people lot’s the agile way by focusing on a set of practices, forgeting the agile values and principles. They are focused on doing agile, and they forgot that depending on your experience, if your are a beginer in a practice, you need clear directives to learn how things work, and more and more your skills are developing you will need coaching on the go, and then you will need some support, and then you will be fully autonomous and during this journey you will have adapted the initial set of practices living the agile values and principles.

    That reminds me the stickers I had printed for an agile conference:
    sticker-agile-tour-2013-v2
    When I recieved the stikers at this point, I was thinking… humm I should have crossed also “be” and put “learn” instead… because this is really what we are doing here…

    So Mark proposed those 4 high level ideas that can become the high level principles we can refer to as an Openstack contributor :

    diverse interests, but a shared vision, based on consensus
    individuals and interactions over processes and tools
    leadership through empowerment, empathy and trust
    every advance must ultimately iterate from the bottom up

    And I encourage you to watch the talk to understand the details of his proposal.

  • Happiness is Coming

    Happiness is Coming

    I had the great pleasure to deliver the opening keynote of April 17, 2015 of the Drupal Developer Days in Montpellier. The selected theme was Happiness…

    Here are the slides:

    And a selection of tweets:


    Thank you for your great feedbacks and for the great conversations that followed!

    I feel ready for the next DrupalCon 😉

  • 1500 développeurs dans mon équipe

    1500 développeurs dans mon équipe

    1500 développeurs dans mon équipe est le titre de la session que j’ai eu le plaisir de donner lors de l’édition 2014 l’AgileTour à Bordeaux.

    J’apprends l’agile depuis déjà longtemps en pratiquant et en partageant les valeurs, principes et pratiques avec des clients et d’autres pratiquants. Et c’est peut-être depuis que j’interviens au contact d’Openstack, un logiciel libre d’infonuagique (ou si je parle en presque français “a cloud open source software”) que j’ai appris le plus.

    Ce que j’ai appris ? 

    2014-10-31 15.15.17J’ai appris que l’on pouvait créer un produit avec une équipe de 1500 développeurs répartis sur tous les continents, que l’on pouvait avoir la certitude de délivrer les nouvelles versions à date fixe tous les 6 mois, que le processus de revue de code apportait beaucoup plus de bénéfices que ce que j’imaginais au départ, que la gestion des branches de développement pouvait être plus simple et plus efficace. J’ai aussi appris que la socialisation, l’accueil des nouveaux arrivants, le maintien du lien était une chose très importante… 

    L’idée de cette session est de partager ces apprentissages pour que vous puissiez vous en inspirer dans vos organisations.

    Et bien sur, il ne s’agit pas de “mon” équipe, mais de l’équipe qui contribue à Openstack… Et il n’était pas 1500, mais 1419 à avoir contribuer à la 10ème version JUNO publiée le 16 octobre 2014.

    La photo d’entête est de Anne Gentle (License Creative Commons 2.0) Il s’agit de la vue de la salle pour la Keynote d’ouverture lors du Summit à Hong Kong en Novembre 2013.

  • ALE 2014 – deuxième et troisième jour

    ALE 2014 – deuxième et troisième jour

    Cet article évoque les deuxième et troisième jour de la non-conférence 2014 du réseau ALE (Agile Lean Europe). Le résumé du premier jour est ici.

    Ce deuxième jour de la non-conférence ALE 2014, débute par une session par Josef Scherer, Self-designing Feature Teams @BMW. Pour influer sur la culture d’une grande organisation, Josef explique qu’il est nécessaire d’établir une structure permettant à la culture d’exister ou d’évoluer. Josef a ensuite présenté les structures d’atelier permettant à des équipes de se recomposer en équipe dédiée à des fonctionnalités (et non plus par role dans un processus en cascade) et cela en moins d’une demi-journée.

    Stephen Parry prenait la suite avec un approfondissement de sa session de la veille pour créer une organisation en capacité d’apprendre et de s’adapter. Stephen parle ici de créer les conditions, le climat permettant le développement de cette culture. Stephen a présenté l’application du diagnostique Climetrics mesurant le climat dans les organisations suivant 4 axes : Engaging, Learning, Leading, Improving. L’exemple présenté montre que pour passer d’une organisation « diriger et contrôler » il ne s’agit pas d’avoir des objectifs d’amélioration continue, mais une transformation complète de la façon de faire. Comme dans les exemples de la première session, ce sont les équipes qui ont dessiné la nouvelle organisation (et pas le management).

    Paweł Pustelnik présentait comment créer et faire croitre la culture de leur organisation Future Processing. La culture se voit dans l’atmosphère, dans le climat présent dans l’équipe, dans les valeurs que les membres partagent.

    Great Software… because we put people first.

    J’ai trouvé intéressante l’idée d’habiller un des couloirs de l’entreprise avec les événements importants de l’entreprise depuis sa création, ainsi que celle du mur de photo de toutes les personnes de l’entreprise, également importante. Le support de Pawel est ici.

    J’ai malheureusement manqué les sessions de lightning talks (probablement le meilleur me dira plus tard Pablo).

    Les sessions de Pecha Kucha (20 slides x 20 secondes) était excellentes :

    • Christof Braun – Trust me – this is important
    • Alberto Brandolini – The final words about software estimation
    • Martin Klose – Coderetreat – perfect practice makes perfect
    • Pawel Brodzinski – Building Teams – We got it all wrong!

    J’ai butiné au cours de ces sessions open space et participé à une seule excellente session celle de Sabina Abdulajeva qui nous faisait prendre conscience de notre corps.

    Felienne Hermans concluait cette deuxième journée en proposant : “Putting the science in computer science“. C’était assez amusant d’essayer une approche scientifique sur une question troll : “quel est le meilleur langage de programmation ?”. Il s’avère que la réponse des participants ne dépends d’aucun des critères que l’on entends régulièrement cités pour défendre tel ou tel langage, mais dépends principalement de la disponibilité de librairies open source.

    Le troisième jour débutait par la Keynote des enfants. J’ai oublié de préciser que ALE est une conférence à laquelle les époux(ses) et les enfants sont invités à participer ce qui contribue également à une ambiance particulière. Les enfants ont donc préparés une keynote au cours de laquelle l’ensemble des participants ont contribué à peindre une fresque avec leurs mains.

    J’ai ensuite proposé une session “The Agile and Open Source Way” et j’ai obtenu enfin les feedbacks qui vont me permettre de faire évoluer radicalement le contenu de la session et d’augmenter son impact et son utilité (un grand merci pour ceux qui ont pris le temps de me donner des feedbacks).

    C’est Olaf Lewitz qui a gagné l’opportunité de proposer un talk surprise. Il a choisi de nous proposer sa session “De-scaling your organization“. C’était excellent et inspirant, à la fois sur le contenu et la façon de le proposer.

    Pour les lightning talks, l’émotion du moment ne fait retenir que le talk que ma fille Emma (12 ans) a donné (et en anglais). Merci à tous les participants pour leur enthousiasmes et leurs retours positifs.

    Les sessions de Pecha Kucha du jour étaient excellentes également :

    • Oana Juncu – Key ingredients of storytelling
    • Antonio López – Using Social Network Analysis for an Agile transformation
    • Shannon Jean Ewan – Agile processes evolve. Agility is here to stay

    J’ai participé à deux sessions open space, celle proposée par Olaf Lewitz nous a fait découvrir le personality poker et nous nous sommes dit avec Pablo que nous allions le traduire en français, et une en vue de la préparation de la conférence de l’année prochaine : ALE15 (oui j’y pense déjà et j’y serai).

    Jennie Jepsen assurait la Keynote de cloture et faisait une nouvelle fois référence à la science (celle du fonctionnement de notre cerveau cette fois) pour expliquer nos problématiques de transformation.  Cela a au moins le mérite de rappeler que lorsque l’on dit science, on dit approche scientifique et qu’avant de s’intéresser à des résultats, il faut s’intéresser aux protocoles des expériences.

    Un grand merci à Future Processing pour ces actions dans le cadre du sponsoring de cette édition ALE : Massage (avec les masseuses qui travaillent habituellement chez eux à temps plein), Soirée… et j’ai même gagné un cadeau en donnant une définition de ce qu’était faire du développement agile : “Build a product with all the emotions and intelligence of the team”.

    Un grand merci à tous les participants, intervenants, organisateurs (quelque soit leurs roles) pour cette excellente édition !

    Les liens depuis les noms des intervenants cités pointent sur leurs comptes Twitter, et je vous encourage à les suivre !

    Les photos d’Olaf, de Pablo, de Tomek, de Antonio

  • Open Innovation

    Open Innovation

    Ce 12 juin 2014, une annonce d’Elon Musk, le CEO de Tesla Motors, est venue secouer l’écosystème automobile.

    L’annonce titrée : All Our Patent Are Belong To You, déclarait que toute la technologie développée et brevetée par Tesla,  était à présent disponible pour qui voudrait l’utiliser, de bonne foie, dans l’esprit des projets Open Source.

    Je n’ai pas encore vu si cette annonce allait être suivi d’une ouverture plus forte des travaux de Tesla, avec peut-être des possibilités de contributions d’autres acteurs du domaine, sur une plate-forme ouverte, avec la mise en place de licence Open Source… Mais ce premier pas est déjà énorme.

    Cette annonce a reçu une pluie de commentaires positifs et attiré aussi des détracteurs expliquant que l’intérêt de Tesla n’était pas qu’altruiste puisqu’ils tireraient bénéfices de cette ouverture en faisant émerger leurs solutions comme des standards.

    J’apprécie évidement que ces commentaires fassent ressortir un des bénéfices d’une approche Open Source. Celui de faire que les contributeurs à une solution, plutôt que de gaspiller de l’énergie à se combattre à coup d’incompatibilités, fassent émerger des standards permettant de mutualiser les ressources.

    En tant qu’utilisateur, je serai très heureux de pouvoir brancher mon auto sur n’importe quel système de n’importe quelle marque.

    J’en profite pour mettre en avant deux articles, le premier du CEO de Red Hat tirant son chapeau à Tesla, le second dans OpenSource.com revenant sur les réactions variés suite à l’annonce.  Et dans le premier, Jim Whitehurst parle aussi d’eNovance

     

    Le choix du titre de l’annonce est plutôt drôle n’est-ce pas ? Si vous vous demandez pourquoi, jetez un oeil à cela : All Your Base Are Belong To Us.