| | APRIL 20199CIOReviewsoftware, we rely on bug reports. That's our feedback to what's working and what's not working.But your open source software won't get far if your default response to bugs is to make excuses. If a user discovers a problem in your software, you need to accept that feedback, fix the bug, and move on. If you instead respond with excuses ("But I did that because ..." or "But that's something you should avoid anyway") then your open source software project is doomed to fail.Similarly, in leadership, you need to accept feedback and comments, from all quarters. Feedback is a gift, and we should seek out feedback so we can improve ourselves. At the end of any large meeting, I like to pause and ask for feedback. A simple exercise to identify what worked and what we should change next time helps to keep things on track.When soliciting feedback, your audience needs to know that you will listen to what's said. Resist the temptation to respond with excuses ("Well, we did that because ...") but instead accept the gift, and say "Thank you."We all need to hear feedback from others, even if that feedback is difficult to hear. Managers who receive feedback from their staff become more effective managers, including coping with their emotions, empathizing with individuals and resolving conflict. But managers who do not receive feedback from staff are less likely to change their behavior.Everyone brings different viewpointsAnd those viewpoints make for a stronger open source software project. Eric Raymond coined "Linus's Law" about open source software development, claiming "Given enough eyeballs, all bugs are shallow." (Raymond, The Cathedral and the Bazaar, 1999.) More properly, the law states "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone."When you have many developers involved in an open source software project, the solution to a problem will be obvious to someone. But one developer working alone may find they are stumped to find a resolution.The same holds true outside open source software, in any organization. We don't have all the answers. As a friend and colleague often advise, "the answer is in the room." I find it helps to prompt a conversation with "How might we accomplish this?" The phrase is open-ended and encourages participants to find a solution.You don't have to do it all yourselfIn open source software development, it can be tempting to do everything on your own. Many people get into open source software for the sense of accomplishment, and there's nothing like creating a software package on your own to feel like you've really achieved something.But you won't get far in open source software with a "do it all yourself" attitude. In any sufficiently large or advanced project, you need to work together with users and developers.Years ago, a mentor helped me realize that an effective leader delegates. I used to struggle with delegation; I always thought I could do it better myself. I feared that someone else might do the task incorrectly, or at least not to my preference. But we can't do everything; we need to pass on assignments to those in our teams, and trust that they will do the right thing.Looking for leadership lessons through the lens of unexpected sources can be interesting and insightful. We need to find inspiration from everything we experience. For myself, I like to reflect on what I have done, to find ways to improve myself.As chief information officer, I leverage many of the lessons I learned from maintaining or contributing to open source software. While I find insights from other areas, experience drives learning, and my twenty years of personal experience in open source software has taught me much about accepting feedback, listening to others, and sharing the burden. This applies directly to my professional career. Looking for leadership lessons through the lens of unexpected sources can be interesting and insightful
< Page 8 | Page 10 >