Over the years, I've built up a few of my own leadership philosophies based on what I have learned through experience,and exposure to DevOps and Lean. In this video, I'm going to share a few of them, and explain why they're important to me. The first one is honor and extract reality. I used to only say honor reality, and over time, I realize that it's one thing for a leader to honor reality, but it's even more important for a leader to have the ability to extract reality. Let me share an example. If a team encounters complexity as they are developing a feature, and they surface that to leadership to get help, the way a leader responds is extremely impactful to the culture. I try really hard to accept the reality of the situation and focus more on the path forward, figuring out what we have learned and how do we help the team get unblocked. After observing behaviors with leaders over the years, I added extracting reality because I saw a lot of examples where leaders responded negatively by ignoring or shooting the messengers. If that becomes a pattern in the organization, then teams will stop surfacing reality. I have been in situations where I've started working with a team where they were not encouraged to surface reality. So, I've had to build up trust to make them feel safe again. That's what I mean about extracting reality. Simple techniques I use include; what questions I ask. I never ask who, I always ask how. It completely changes the dialog. If a leader uses who, teams immediately feel like it's about blame or failure leading to scapegoating. If instead a leader asks, "How can I help?" Then the team sees that the leader is genuinely curious. Failure leads to inquiry. Another philosophy I have is understand the work. Over time, I've added some qualifiers to this. In essence, I'm trying to capture the concept of gemba, which is a Japanese term meaning the actual place. Leaders need to go to the teams and the work. When I first started talking about this, some of my peer said, "That's micromanagement," and I responded that the purpose is to go and see, not go and tell. I truly believe that leaders can only be helpful if they truly understand the work, and by going to the teams, it demonstrates the commitment to learning and being a problem solver along with the teams. Two of my philosophies that are closely related are; human error is not a root cause, and there is no single root cause. You can also find a lot of industry materials related to this. Again, this ties to creating a generative culture. If an incident occurs and the first question is who made this happen? Then teams typically respond with fear. It's more important to talk about what broke down in the system, and ask the team or individual how could we learn from this. The comment about not having a single root cause is related to the recognition that we are working with complex systems. In complex systems, there are multiple contributing factors when an incident occurs, and it's more important to focus on learning versus finding a single root cause. In fact, it's a fallacy and leaders who say things like, "I want assurance that this will never happen again", are creating the wrong environment, and not encouraging a learning environment. This is a good segue to another philosophy I have, leading by example, which means making sure your actions match your words. I've seen a lot of leaders say they believe in creating a generative culture, but their actions don't align to that especially when things go wrong. These next two are closely connected. I believe that I'm accountable for providing strategic direction and also prioritization, focus, and discipline. When done well, this can help minimize context switching and allows for the next philosophy which is to empower teams and individuals. Early in my exposure to DevOps and Lean, I had a lot of conversations about empowerment, and often, I felt that I was empowering my teams. However, I found that it wasn't enough to just say it and allow decisions to be made locally. What was also required was to provide intent, context, and accountability. If that happens, then teams are truly empowered. They have clear direction and line of sight to the outcomes they're accountable for, and can ground all of their decisions in the context. I also personally strive to be a lifelong learner. I try to be very active in the external community and learn from others. This also includes trying things that force me outside of my comfort zone. I learn so much when I'm experimenting, it's not easy and requires persistence. I've realized though that every new experience has given me additional knowledge, and depending on the scenario, has helped me build up resilience as I take on new challenges. I already mentioned this, that people are the organizations number one asset, and I believe and respect for the individual. Lean is all about respect for people, and I make sure this is the foundation of all of the other leadership philosophies I've built up and continue to practice. Ultimately, my goal with DevOps is to create high trust and a generative culture. I think that after watching this video, you can see why it's important to try and take our organizations in that direction.
