Hi everybody. I'm Greg Lind, CEO, and founder of. build these a software architecture as a service, company. We have, open source products and, products, labs, which is our, product management through ai. And, Product managers, human as human oversight. Also, managing partner at Open Build where we do, open source management programs and mentorship programs for junior developers to senior and senior to CTO. but we're here to talk about, radical therapy for software teams. we wrote this book over the last couple of years, but the focus on it, was really about transparency, and how to use that as a team, tool to build for, successful teams. it's a lot about the fusion of dev and product teams, which is also what we've built into Build Link. it's a big. milestone for us because we've also added that to our, AI built-in knowledge for our product manager. So you can actually use the tool and get some insights from the book as well. but we'll go into in depth today a little bit about. How to get started with, radical transparency as well as, therapy for your software teams. and we will get a little more, deeper into what those mean. So radical, obviously for us, it means something that's, fundamental, changing something at a drastic and a far reaching effect, right? not radicalness in Jeff, right? So we're not talking about surfers, we're talking about radical. It's a big change. And therapy. obviously I'm not a licensed therapist, but I do see a lot of, software developers in my, as a manager and as I work with as colleagues. that need help often, outside of work sometimes, but related to work, having to deal with things and you start to feel, if you've ever managed a team or if you've ever managed a product, you know how it can feel sometimes. Like you're also helping. I. Folks through struggles, you're helping them, to build their trust, accountability with them and with each other. so a lot of times you feel like a professional therapist, right? But maybe you just play one on TV or play one in product management. So we'll go into a little bit more on that. but let's start with the transparency. specifically the principles, but transparency, first off, which is really just about open communication, encouraging clear and honest dialogue with each other and with your team as well as with the larger organization, right? Transparency, however you're working, if you're on a startup or a big organization. Having a clear and transparent process as well as, open dialogue with the rest of the organization's only gonna help remove blocks. I think the other side of this is data-driven decision making, right? So collecting data and using it for how, for your product to make it better as well as help to even improve your process and your team. So part of this is about taking things. From Agile and other things like that and adapting it to use it in a cloud native way, a microservice driven way maybe, but also multi repository way. And how to use that to better make decisions when you get data, and be able to apply that to your decision making processes. Part of that's feedback, ongoing feedback throughout your process from your team, as well as eventually your customers and bringing that into the process. And then, inclusivity and diversity. I. diversity in terms of perspectives, as well as, diversity in terms of the types of folks you're bringing into your team. ensuring that all of those voices are heard. and really part of the diversity approach to this is also about just getting those different ideas, right? Hearing, different perspectives gives you a better product as long as you're willing to actually adapt and use those. and then bringing your backlogs. Product backlog and merging it with your developer backlog, right? So having one process where everybody's seeing where everything's doing it, and that's a lot of what we do with product labs at ly, but it's also just about a simple way to do that in terms of process overall. So we wanna break down silos. Be more efficient. promote cross-functional communication, collaboration, and then share insights between DevOps, product teams, managers, developers, all of that, transparency, optimization, and, reduce your time to market, right? Build something, do it quick, and then, but focus on quality and focus on feedback. That's really the best approach for this is, and starting with that is data-driven decision making. So helping you to make decisions faster. one of the best ways to do that is to get feedback, And bring that into your process. And then you are also getting higher engagement and retention that way. People that feel invested in a product are people that feel like their voices are heard in the process, as well as just feedback in terms of what they like about the product and what they would like to see in the future. you're also reducing conflict and resolution time. When you're bringing in, you can show a data point and you can show how to get through a conflict by just. Showing to them, to a team member, to a, a customer, to a manager. If you can show them data, they're obviously gonna be able, much easier to persuade. So some companies that bring this decision making process and radical transparency in Atlassian's a great one. Google has a great, process where they bring in, Teams and cross-functional teams that share, developers to share members across each one, right? So they move back and forth. They all have the same process, but they learn from each other by sharing team members across. Zappos is another one that had the same sort of process and, Trust and ethical AI implementation. IBM and their fairness, 360 and Netflix and their responsible AI toolkit. I'm not sure how much they're still implementing that at Netflix anymore, but, they do have some great processes around how to, bring responsibility in ai and that helps you bring, better data and better decision making processes, right? So key steps. Establish a culture of open communication. again, that means, sharing what you've done right from day one. the scary thing for developers when they come work with us at LY is, day one, you need to commit code. I. It doesn't matter what type of, product you're working on that we need to see that commit. Go into a branch, that's your branch and you're gonna get feedback on it. It's gonna be a little scary at first. it's definitely unusual for some. But, we also focus on, positive feedback, right? And making people feel good about those steps, getting those first movement into this process. Again, data decision making processes accessible. So that means, not only do you need to share. What you're doing, but how you came to that decision, right? So where did that come from and how to make that more accessible is just by opening up your process, opening up your backlog to your team, to your customers. everyone should have access to that and encouraging that feedback and asking for it, asking for criticism, hopefully constructive. but certainly within your team, you can ensure that it's constructive criticism. And then, introduce transparent performance and compensation policies. So a lot of team conflict, doesn't revolve around compensation, but within an organization, within a management, if somebody's unhappy, usually it's because of compensation or it's because of people that they're having to report to or sometimes too many people to report to, right? So being transparent around performance and how to get better. And sharing those compensation policies and showing people how to move forward both within your team and within your organization, and then integrate those transparencies into product development along with AI ethics, right? So everyone's using AI for something now. you need to make sure that when you're testing that ai, it's not just about. the LLM that built it, right? You need to test it both from your production standpoint to see what people are, actually sending to your ai, models and then also from your own, processes and tools. How are you actually testing it before it goes out, and how are you making sure that those ethical compliance tools are embedded in that process so that you're making sure that. It's not weighted in one direction or that it's not, doing something that you don't even know when it's suggesting to your customers. let's talk a little bit about enhanced innovation and problems. So diverse teams bring very perspective, right? So what we wanna look for in diversity is. Innovation, right? So in diversity helps drive innovation and problem solving. So diverse teams bring varied perspectives leading to more creative solutions and better decision making processes. Stronger team performance and productivity in inclusive teams prove, this is a McKinsey report that showed that 35% better performance by leveraging different experiences and skills versus non-inclusive teams. That means. If you have a team that's diverse and has a lot of different perspectives, you're getting better performance as well as a better product out of that, right? And as a variety of skills. Along with that, better representation and market reach, a diverse team reflects the reality of who you're trying to sell to, right? So the, if you want to build something that's user friendly and competitive, diversity's gonna help with that, right? Who's this guy? This the cheerleader, right? So what, when we say we're talking about, Being positive, right? And we're talking about being, an encouraging person on your team. It doesn't mean go out and be rah, yay, and super positive all the time. it means trying to keep your team positive by helping them with ways that help sometimes, especially software developers aren't comfortable, talking. Communicating. But helping them get out of their shell, helping them get out and be part of the team is important. And that means doing that in a careful and thoughtful way, and not in a, in your face kind of way, right? So team morale is important. You wanna focus on trust. Safety when somebody's in that team promote transparency and with team members, but also try to reduce the stress and workplace anxiety around it, right? Encouraging open communication with daily check-ins. Those can be online in Slack, which most people are doing now. If ideally, you're doing it face-to-face so that you can adjust, right there real time. But if you're not, online is great as long as people are actually reading. Those contributions. A lot of times when we do Slack check-ins, I'm the only one that reads those things and you, that's great because I can help remove some blocks and then I can go back through and make some changes. But you really need to get your team involved in making sure that they're reading that as well. Celebrate wins and reduce burnout and frustration. A clear one of the goals around. This whole process has been to help people feel more comfortable, within teams and feel like they have a path forward, and upward. And one, the, one of the ways to do that is, is to really celebrate and show growth, but also really focus on folks that are down like that are having a rough time helping to bring them up, both from your process and your giving them clear goals, but also just from how you work with them. What tools are they working with? Maybe they're getting, Over, burdened with too many tools, or maybe they're, they don't have the right tool yet. so a lot of it's about that as well. And then empowering folks with autonomy and ownership, right? Employees have access to information and decision making. They feel more accountable and invested in their work, and that helps them. To feel like they're part of that team, they're part of that product and they wanna see it grow. They want to see it get better, right? So you wanna run a product like a lean startup and run a startup, like an open source project. How do you do that? And why would you do that? One? It encourages sharing work openly and asking for feedback, right? That's what open source projects want. Like maybe they aren't great about adapting to it, or they get overwhelmed by it a lot of times, but that is what they want and that's how we wanna bring that process back to a startup. Same thing with the startup. A project that you're working on inside your organization, right? A larger organization still needs to feel like there's communication, like there's a path forward, for everybody and promoting a community that, con contributes to that creates innovation, right? Every organization wants to have innovation. They wanna drive that in their products, in their projects, and that means bringing that process in. And emphasize the importance of building inclusive communities while you're doing that helps you bring innovation, but also helps you bring everybody along with you and embrace competition, build new markets, right? you don't, just because I. Something existed already, doesn't mean you can't make it better. Why not build a better mousetrap? I hate that analogy of don't try to build a better mousetrap, but the reality is there's plenty of products that are okay, but they don't quite fit. So make the product you want. And if it's not in the marketplace, go out and do it in the open. Start sharing it right away, or build your dream product and then share it. Obviously you wanna bring the users along with you as much as you can, as early as you can, but I. Don't be afraid to build something just 'cause there's already a version of that. I, my least favorite thing that people say to me about, but this tool already does that. Yeah. But it doesn't fit for my needs. And that's okay. they're gonna want competition 'cause it opens up their market. So we want to, we wanna focus on innovation. We wanna focus on getting things better. That means going ahead and building some that better mousetrap. You said opposite example of someone who built something very privately, a potentially very innovative product. but everything was hidden from the users and it was difficult for every, everyone involved to understand. 'cause there was no transparency. So Theranos a very. Famous story for most people in the startup world, really in any product world, was built behind closed doors, hiding things from investors because they weren't making the progress that they thought they would, trying to keep it proprietary everywhere they could. And using the old fake it till you make it approach, which in the end. Really came back to bite them. So transparency would've helped a lot from the very beginning, right? Building something from the start. Who knows where they could be? Now? now, I don't know if they, I obviously was not involved in this, but I don't know if they had a better product in mind and it just didn't come through or the idea was to fake it. But I don't think so. I think they were trying to build something truly revolutionary and it just. One person had too much control, hid things, and was just not able to make it happen, right? So lesson learned, hopefully for a lot of people. so let's talk about the radical process, right? So we know Agile, scrum, lean, all of these different, tools. and they work great for a lot of different situations. but I think. In a cloud native environment, there's some things that are missing in that, right? I think, one of the things that we wanna focus on in our process is building trust with the product team and the development team. agile tins and Scrum tends to separate you out, right? You've got the pigs and the chickens and all the different things that they talk about there. And the reality is we're all coming, need to come together to build that product, right? But not everybody needs access to everything all the time. But they do need some sort of idea of what's going on, how to work with that product. They want to be able to ha put their voice into it, but they want, they wanna feel like it's constructive and they're not interrupting. So clear communication, bringing the process back to the development cycles, but also bringing it back to the product management cycles, the marketing cycles, the design cycles, all of that into one. Radical process, right? Where we're building everything from the start. We're not building artifacts, we're not building documentation necessarily. We're building a product that means stakeholders are included from the beginning, and that's developers are stakeholders too, right? Product managers are stakeholders, as is management, and C-E-O-C-F-O, all of those people, especially marketing. Need to be involved in at certain steps. So the more clear you are, the more open you are from the very beginning, the easier it is to bring them in. aligning your team across all of these different silos helps to remove those silos when you need it. And then bringing that feedback in, right Surveys, bringing in through, process tools, bringing in through direct demo days, so that you can actually show progress. and when you make a mistake, be open about it, right? And let people know. 'cause the worst thing that can happen is there's a mistake out there. There's a bug that brings down part of your application. Hopefully just part of it, not all of it. and. You didn't tell anybody and they find it, it's much easier if they know ahead of time, right? It's hard. It's a hard lesson to learn, but that's. The best thing you can do. And then when you do make that fix and you do get that first release out, celebrate that with your team, with your users. again, don't be a cheerleader, but just, acknowledge those wins because they're sometimes few and far between, but you still wanna be able to show that the team's making progress, So it's not about the tools necessarily, but it is also about the tools, And for us, building labs where we do product management and communication, that our whole process is about removing those silos and letting people in without having to directly connect them. So one of my least favorite. Problems is when a CEO has access directly to a developer, right? Or a developer is asking questions of a product manager. They don't know how to answer that, and so they go to the CEO or the manager and have them talk directly to the developer. that can be distracting for everyone involved, and nobody wants to be involved at that level necessarily when they're thinking about high level things. So bringing, breaking down those silos, sharing code from the very beginning again, like we talked about, and then communicate through Slack or whatever tool you like, but making sure that is updated consistently and everybody has access to it. Now bringing philosophies and politics and everything else into a, an organization is not a good idea usually. But I think when you're talking about finding the team that fits best, right? And openly communicating, like some of that is about stakeholder inclusion, but it, some of it's also about transparency and why are you involved in bringing that, that up right from the very beginning. So open communication. Builds trust, right? With customers and your team. Transparency tends to attract like-minded individuals, people that also like transparency and it brings loyalty to your employees. I think you, loyalty can be a bad word for sure. I. You don't like, but what you do want to have is people that want to see that product succeed, want to see your organization succeed, including them from the very beginning. That's how that happens, right? So start small, really gradually scale up your transparency efforts. but don't be afraid to bring it to your organization, whatever that size it is, and start to get buyout from the top down. open build is a product and a organization that's really. dear to me in terms of its approach to open source, helping open source, as well as helping developers learn. So it's a thing that's missing a lot in organizations right now is, mentorship. So open build is a place to do that if you're interested. again, check out the GitHub repository, come back and talk to us. we're expanding quickly with that. We've got a lot of different developers going through that process, and we're always looking for more. the Product Foundry again, build Lee is focused on all of the ideas that are inside of the Radical Therapy book. but it's also partly, built around a process that's documented in that book as well. if you're interested in learning more about Build and our Foundry program for startups as well as just products in small, who wants to learn more, and, yeah. Thank you very much for listening.