Tag: systems thinking

  • There Is No Shortage of Leaders

    I like the way Jerry Weinberg defines leadership.

    Leadership is a process of creating an environment where people become empowered.

    Empowerment

    I don’t really like the word empowerment as it is frequently used in the context of making people empowered. The way I understand empowerment such thing can’t even be done. You can’t empower me to do something.

    What you can do is give me enough positional power and possibly encourage me to do something. I can still cease to do it because of a number of reasons. I may not see value or sense in doing that. It may move me too far outside of my comfort zone. I may be afraid of peer reaction. Finally, potential consequences of failure may drive my decision.

    The way I think of empowerment is that it is intrinsic. I can feel empowered to do something. What others can do is they can create conditions that would enable that. It means anything from creating experiments that are safe to fail to shaping the environment so it supports and not discourages me to act.

    Only such way of interpreting empowerment makes Jerry Weinberg’s definition of leadership reasonable.

    Process

    What Jerry Weinberg talks about is a process. That’s unusual as typically when we think about leadership we think about individual context. How to become a leader or how to become a better leader.

    What “a process of creating an environment” communicates is that a discussion about leadership should happen in a different context. Instead of wondering how to help an individual to become a better leader we should discuss how to build an environment, or a system if you will, that supports emergence of new leaders and further development of existing ones.

    This inevitably brings to a context of system thinking.

    If we consider an organization a system there are many of its properties that influence whether, how and when people can lead.

    One of the most obvious ones would be a formal hierarchy. How rigid it is and how many levels it is built of. A hierarchy is important as it often linearly translates to power distribution. Most often it would be managers who make most decisions and influence environment around in extent.

    Then we have all the rules that people are supposed to follow. What is allowed and what is not. What stuff I have to comply to before I can do things I want. And most importantly whether everything is allowed unless rules state otherwise or the opposite: nothing is allowed unless rules state otherwise.

    Thinking of an organization as of a system from a perspective of enabling leadership is important because the system defines constraints. Normally, one can’t go beyond these constraints without risking dire consequences.

    In other words structures and rules define how much potentially is possible in terms of catalyzing leadership. It doesn’t automatically mean that fairly flat hierarchy and few rules is enough to see emergence of leadership throughout a company.

    Environment

    The bit that enables fulfilling potential created by rules and structures is organizational culture. We define organizational culture as a sum of behaviors of people being part of an organization. It’s not only abut behaviors though. It’s also about what drives them: values, principles, norms, beliefs, etc.

    Organizational culture constitutes what is an environment we work in. This is what steers how far we would go within existing structures and rules. In fact, it may even let us break the rules. It may be perfectly acceptable to for an organization to go against the existing constraints as long as it means doing the right things and is aligned with organization’s values and principles.

    What’s more, for companies that aim for good leadership distribution across the board will likely encourage such behaviors as it is a crucial condition for evolving the system and the culture.

    The hard part about organization culture is that we can’t mandate its change the same way as we can mandate for example rules change. We can’t do it as the culture is a derivative of behaviors of many people.

    What’s more we can’t mandate the change of behaviors in a sustainable manner either. We can introduce a policeman who would make sure people behave the way we want them to, but the moment the policeman is gone people would retreat back to the old status quo.

    So what can we do with the culture? We can work on constraints. This is in fact aligned with a system thinking view of an organization.

    A Process of Creating an Environment

    The bottom line of this is that most of the time when I hear complaints about not enough good leaders it is because environment is designed in a way that doesn’t let them emerge, let alone thrive.

    A litmus test that I use to quickly asses what climate there is for potential leaders would be bringing up famous Grace Hopper’s words:

    It’s easier to ask forgiveness than it is to get permission.

    The question to ask is how much of that attitude is present in an organization. An interesting observation is that the more people exercise that attitude the less they actually need to ask forgiveness.

    The core of it though is empowerment. On one hand it translates to taking the rules into account and then doing the right thing even it means going beyond the rules occasionally. On the other it means that an organization accepts and supports such behaviors. It requires involvement of both parties.

    It requires continuous effort to adjust rules and structures and evolve an organizational culture to reach such stage. It requires a lot of discipline across management on all levels not to break such attitude once it is present as it is fragile.

    That’s why it’s a process and not a thing. Good news is that the better you do that the more leaders would get involved and the more self-sustaining the process will become.

    At the end of the day, there’s no shortage of leaders, only a shortage of companies that let leadership emerge.

  • It’s the People, Not the System

    When I first learned about the D. Edwards Deming’s idea that 95% of performance should be addressed to the system and only 5% to the people it seemed totally counter-intuitive to me. Not even the idea itself, but its consequences. I mean a simple thought that you can basically stop working individually with the people on their performance as it just doesn’t make any sense. The impact of suboptimal system improvements should be tenfold or better than the best possible people-related changes.

    Then, after researching the subject a bit, I swayed to the other side. The examples shared by Deming or Eli Goldratt are undeniable. I can also find a lot of examples from my own experience how the system was impacting performance heavily. Not that I had the numbers, but it resonated well with me.

    Now, finally, you know what I think? Both approaches are crap.

    Yeah, I’ve just tried to piss of both: guys who strongly believe in Deming’s work and those who totally disagree with him with a single attempt.

    What Deming Really Said

    I guess this story started when I was looking for precise Deming’s quote on one occasion. It seems that the meaning people attach to his words wasn’t there initially. The original 95/5 thingy was not about performance literally but about variability in performance.

    Let me use a sport analogy to explain that. Let’s take a basketball player. If he scores anything between 5 and 30 points a game, and neither of extremes is an extraordinarily good or an extraordinarily bad game for him (meaning: it happens on occasions) variability of his performance is high. As a comparison we can have another guy, a second-tier player, who regularly scores anything between 0 and 5 points. Variability of his performance is significantly lower, even though his average performance is significantly worse.

    Now, it’s not a surprise that the system governs variability. I mean, the more repeatable the situation the less variability you can expect. If the team plays are consequently set to create situations for one player his performances will be sort of repeatable. He won’t be suddenly disappearing from the game. At the same the system also governs variability of performances of a role-player who joins the game only under special circumstances, e.g. when the team needs more three-pointers or maybe when one of important players is injured. Variability of performances of such a player will be significantly bigger.

    Of course, to some point, the system also governs performance itself. Think what happens when the star sits on the bench throughout the whole game or when a guy who is typically a sub plays the whole game. It doesn’t mean, however, that you tell a third-tier player to substitute a team leader and expect them to score 30 points a game. It’s not going to happen in a consistent manner. (For basketball fans: yes, I know Jeremy Lin’s story, but that’s an exception.)

    What Deming was talking about was basically that the system governance is responsible for creating a stable and repetitive environment so people performances are controllable. Again, it’s not about how exactly people perform, but how their performance varies from day to day.

    In fact, the above statement is mostly an interpretation too. Deming was talking about the system being, or not being, in statistical control which isn’t exactly performance variability, but for the sake of this argument let’s leave it as it is and not complicate things even further.

    Anyway, Deming Is Still Wrong

    So far I made an attempt to convince you that: first, Deming was basically talking about performance variability and second, the impact of the system on performance itself, while existent, isn’t anywhere close to 95%.

    However, we shouldn’t forget Deming’s background, which is a factory floor. In other words it’s a place where workers are supposed to produce same things in a repeatable manner. I could exploit the basketball analogy further pointing that every game, heck, every play is different, but I guess in software development we simply don’t need that analogy anymore. It’s enough to ask: how many times have you built exactly the same feature?

    And for all three of you who accidentally had this chance: how many times have you built the feature second time in exactly the same way you did the first?

    I bring this argument to show that in knowledge work, or sports, we naturally have significantly higher variability to deal with. And, unlike on a shop floor, that is good. What’s more, there is a different value attached to every single thing we develop. In fact, it’s even worse than that. Very often we don’t know exactly what value is attached to a work item we’re going to build.

    This means that in such a situation we should use a very different statistic mechanism than Deming based on. We need to take into account both expected cost and expected payoff. The latter, naturally, isn’t taken into consideration on a shop floor as in this situation payoff for each part is well known. In knowledge work, on the other hand, payoff function is extremely important and never flat.

    Coming back to the basketball analogy: if you wanted to bet which player is going to score 30+ points during the next game would you rather choose this reliable guy who averages 15.0 and who always scores double-figure but rarely, if ever, exceeds 20.0 or rather that crazy shooter who (surprise, surprise) averages 15.0 as well but, depending on a day, can score either nothing or 40+ points? Bravo! You’ve just chosen higher variability, which is totally against what Deming taught us.

    This is because you’ve taken the payoff into account. In the former case any payoff is almost impossible as, because of low variability, it’s highly unlikely that the guy is going to score 30+ points. The other case is a different story though.

    Now, especially when we think about product development we are in a betting business. We bet that this or that feature will bring a ton of new users or a truckload of money. We can’t ignore the payoff function. We can’t assume the payoff function is flat. In either case we’d be throwing the baby out with the bathwater.

    By the way, if you want to dig deeper around this one I strongly recommend watching this Don Reinertsen’s session. Twice. Seriously.

    Besides, Who Does Create the System?

    I’m not done yet. I don’t challenge the idea that the system affects performance. I simply challenge the so-called 95/5 rule or, to be more precise, I challenge the way some people interpret the so-called 95/5 rule.

    The question we should be asking is who (co-)creates the system. If we start with Deming he points shaping the system as a management responsibility. This is probably very true on a factory floor. We are not at a factory floor though.

    Let’s stay for a moment within software development perspective and think what exactly an equivalent of a production line is.

    Obviously, one part would be organizational culture. What are general ways things are done in the organization? Does the org use a lean / agile or rather a heavy-weight, formalized approach? How do your clients act? These general rules will be difficult to change.

    However, when we consider a lower level it’s a different game. Let’s try to translate low-level manufacturing process to software development. Production line would likely be a sort of a process: analysis, coding, testing, deployment, etc. What’s interesting though is what is happening on each of these stations. How exactly the work is done? Who makes decisions how the work is done?

    Take coding for example. Who decides whether unit tests are there or not? How many of them? What kind of tests? Who decides on a specific coding style? A manager? Um, no, not really. Most, or even every, of those decisions are made by a coder – a worker.

    Now, the important question: do such decisions define the system which a developer operates in? Obviously! Just think what is going to be the outcome of work of a cowboy coder and what happens when a worker is an eXtreme Programming fan. These are different systems indeed.

    The conclusion of this story is that in our world workers can influence the system heavily, thus completely change the Deming’s equation.

    One might point that leaving people freedom and empowering them is still the part of the system design which is still the management job. I’d disagree. One thing is that adopting a technique or a practice isn’t comparable to moving the machines on a factory floor. I can perfectly start writing unit tests and it doesn’t instantly require everyone else to change the way they work.

    Another thing is that it’s way easier to be a Grace Hopper follower in our industry. We can easily change the part of the system that goes through our desks, no matter whether we are empowered to do so or not. Eventually, if anyone notices (which isn’t that obvious by the way) we should have enough information to have meaningful discussion about the impact of how we’ve done our work.

    All in all, in knowledge work there’s no clear line that separates the system from the people, thus the whole notion of addressing specific part of influence to one or the other is flawed.

    It’s the People, Stupid!

    The last piece of this puzzle is a story. Not that long ago I’ve joined the organization that is exceptional when compared to its surroundings. I’m far from saying that it is a perfect system already, but it’s definitely the most mature company that I’ve ever been working with.

    In fact, it’s not only maturity of software development process we have but also this touchy-feely stuff we call the atmosphere. Not a dream job (yet) but pretty damn close to it when compared to everything else I’ve had a chance to experience.

    Let’s try to translate this to a system definition then. It would be pretty effective. It would be delivering high-quality stuff. It would be a great environment to work at. It would help everyone to grow. How could one possibly not like it?

    The only problem is that I’ve lost one third of technical stuff over the course of few months. The system? No, the people! Their individual needs, frustrations and dreams. Their unique contributions to what the system is, or has been.

    Because at the end of the day, in our world, the system is not machinery with replaceable humanoid parts; it is inseparably connected with the people who operate within the system. Change a single person and the whole system is different. Suddenly the rules of the game have changed and everyone else operates in a very different system. And the only thing that has changed is a single person has left.

    Summary

    My message in all that is that we should first understand our work, how it gets done and what kind of system we operate in. Because when we think about that it becomes obvious that there’s no simple way of separating the people from the system in knowledge work domain, especially when we’re talking about a small scale, e.g. dozens of people, not thousands of them.

    At the same time I’m challenging the common notion of Deming’s rule because it’s nothing close to what Deming really said and it is simply flawed in our domain anyway.

    At the end of the day you should understand the system (obviously!) but focus on the people too if you want a significant change.