Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Category: team management

Why We Fail to Change

I’d love to get a beer each time I hear a story about management imposing a change on teams and facing strong resistance. Literally every time I’d fancy one, I’d be like, “Hey, tell me your agile transformation story.”

One common excuse is that people don’t like the change. That is surprising given how adaptable humankind has proven to be. I’d rather subscribe to the idea that people don’t mind the change; they don’t like being changed.

Unfortunately, being changed part is the story of oh so many improvement initiatives. And Agile implementations, obviously, are among the most prominent examples of these change programs, of course.

So, how is it really with responding to changes?

First, it really helps to understand typical patterns of introducing change. The model I find very relevant in this context is Virginia Satir’s Change Model. Let me walk you through it.

We start with the existing status quo, which translates to a performance level. We then introduce a new concept, which we call a foreign element.

Then we observe an expected improvement, and they lived happily ever after and all. Well, not really. In fact, whenever I draw that part of the model and ask what happens next, people intuitively give pretty good answers.

After introducing a change, performance drops.

It is kind of obvious. We need time to learn how to handle a new tool, practice, or method. Eventually, we become increasingly proficient at whatever that is, and we start to see the results of the promised improvements. Finally, we internalize the change, and the cycle is finished.

Because of its shape, the curve is called a J-curve.

It is an idealized picture, though. In reality, it is never such a nice curve.

What we really see is something much bumpier. It isn’t a straight line to start with, when we maintain the old status quo. Then, it gets way more all over the place when we start messing with stuff. It’s not only that the rough average deteriorates, but also that the worst-case scenario gets worse, and by much more.

It’s pretty much chaos. In fact, that’s exactly how this phase is called in Virginia Satir’s original model.

An interesting observation we can make is that the phase called resistance is a short one that occurs just after introducing a foreign element. Does it mean that we should expect resistance against the change to be short-lived?

Yes and no. Yes, if we consider only the “I’m not even going to try that new crap” type of resistance. This kind of reaction is typically driven by a lack of understanding of why the whole change was proposed in the first place. There is, however, a whole range of behaviors that happen later in the process that we would commonly call resistance as well.

Some people aren’t ready to see even a temporary drop in performance. Once they face it, they suggest a retreat to the old status quo. When facing a stressful situation, many people instinctively go back to what they know best. Unsurprisingly, the old way of doing things is precisely what they know best.

There are also those who are impatient and not willing to give people enough time to learn the ropes. Curiously enough, the last group often includes managers who initially funded the change.

In either case, the result is the same in the end. More resistance.

Inevitably, we reach a pivotal moment. We’ve been through the bumpy ride for quite some time already, and yet we haven’t gotten better. In fact, we’ve gotten worse. Not only that. We’ve gotten worse and less predictable. The whole change doesn’t seem like such a good idea after all.

So what do we do?

Of course, we reverse the change and go back to the old status quo. Oh, and we fire or at least demote that bastard who tricked us into starting the whole thing.

One interesting caveat of the whole process is that a change is not always simply reversible. When we change specific behaviors and yet don’t get the expected outcomes, reverting to the old status quo may be difficult, if not impossible.

For the sake of the discussion, let’s assume we are lucky and the change can be reversed. We are back to old ways of doing things, and we simply wasted some time trying something new. Oh, and we built a stronger case for resisting the next change. We petrified the existing situation just a little bit more.

One reason changes are often reverted is the perceived risk associated with them.

A pretty good proxy for perceived risk is predictability. Typically, the more unpredictable a team or process is, the riskier it is considered. In this case, the important thing that comes along with a foreign factor is how much predictability changes. Not only does performance drop, but it also becomes much less predictable.

While the former alone might have been bearable, the combination of both factors contributes to the perception that the change was wrong in the first place.

There is another dimension that is particularly interesting here. It is the scale of change. How much we change the existing environment: team, process, practices, etc.

We can imagine a series of small improvements, each modifying the context only slightly. The entire series of them leads to a similar outcome as one big change rolled out at once.

We can describe one approach as evolutionary and the other as revolutionary. If we draw inspiration from Lean, we’d call them Kaizen and Kaikaku, respectively.

Fundamentally, the J-curve in both approaches would be shaped the same. The big difference is the scale. The revolutionary change means one big leap and rolling out all the new stuff simultaneously. This means a single big J-curve.

The evolutionary approach introduces a lot of tiny J-curves one after the other. In fact, it is possible to have a few changes run concurrently, but let’s not complicate the picture any more.

What are the implications?

Let’s go back to the scale of the risk we undertake. With Kaikaku, the unpredictability we introduce is much higher than what we’ve seen in the late status quo.

Kaizen, on the other hand, typically suggests changes that are small enough to avoid destabilizing the system nearly as much. It is pretty likely that unpredictability introduced by each of the small changes will be almost invisible, given that we don’t deal with a fully predictable process anyway.

The risks we take with an evolutionary approach are much more acceptable than those we face when rolling out a single, large change.

That’s not all, though.

Another consideration is the duration of the destabilization. In other words, the cycle time of change.

A big change, naturally, has a much longer cycle time, as it requires people to internalize many more new behaviors, practices, techniques, etc. It means that exposure to the risks is longer. Given that the risks are also more significant, it raises the odds that the change will be reverted before we see its positive results.

With small changes, cycle time is shorter and so is exposure to risks. Again, not only are the risks much smaller, but they are also mitigated much faster.

One last thing worth mentioning here is that, so far, we optimistically assumed that all the proposed improvements have a positive outcome. That’s not true.

With the evolutionary approach, even if some of the changes don’t yield expected results, we still gain from introducing others. With a revolutionary approach, each part that doesn’t work simply increases the likelihood of reverting the whole thing altogether.

It is not to say that Kaizen is always superior to Kaikaku. Both evolutionary and revolutionary approaches have their place. We need Stuart Kauffman’s Fitness Landscape to explain that.

Imagine a landscape that roughly indicates how fit for purpose your organization is. It should simply translate to factors such as productivity, responsiveness to the changing business environment, etc. The higher you are, the better.

The simplest and safest way to climb up is to take small steps uphill.

While the approach works very well, eventually we reach a local peak. If we continue our small steps in any direction, it would result in lower fitness for purpose. Simply said, we wouldn’t perform as well as we did at the peak.

If we look only at the closest terrain, we might as well say that we’re already perfect and there’s no need to go further.

Obviously, that would be naive. Or stupid. Or both.

The solution becomes apparent when we take a broader view. If we moved to the slope of another hill, we could eventually reach even a better position.

That’s exactly when we need a big jump. It doesn’t have to automatically land us in a better situation than the one we were initially in. The opposite would often be the case. What is important, though, is that we land on the hill that is higher. That translates to bigger potential for improvement.

Once there, we can retreat back to the good old strategy of small steps that allow us to climb up. Eventually, we reach the peak that is higher than the previous one. Then we can repeat the cycle by looking for even a bigger hill.

Similarly, to the case of J-curves, the picture here is idealistic, suggesting that each change, whether small or large, is considered successful. In reality, it is more the result of experimentation. Some of the changes would work, while others would not.

As you might have guessed, small steps here represent the evolutionary approach or Kaizen. A big jump is equivalent to revolutionary change or Kaikaku. Depending on the context, one or the other will be more useful.

In fact, there are situations when one of the strategies will be basically useless. That’s why introducing change without understanding the current context is simply begging for failure.

One more implication of the picture is that, given the lack of any other guidance, the evolutionary approach is both less risky and more likely to succeed. That’s why I prefer to start with Kaizen when I’m unsure about the context within which I’m operating.

One last remark on Fitness Landscape. What you’ve seen here is a heavily oversimplified view. In reality fitness landscape wouldn’t be two-dimensional. Stuart Kauffman discussed it as a three-dimensional model, although I tend to think of it as a multi-dimensional one.

It means that each change can improve our situation in some dimensions and have an opposite result in others (think: we’ve improved quality, but we are slower). We will have different combinations of effects in different dimensions—some more desirable and some less.

If that wasn’t enough, the entire landscape is dynamic and continually changes over time. In other words, even after reaching a local optimum, we will need further continuous improvements simply to maintain our fitness for purpose. The peak will be moving over time.

I know the post got long by now (thanks for bearing with me that far, by the way). This, however, is only a starting point for discussing why introducing the change often triggers resistance.

I believe it provides a pretty good explanation of why so many improvement initiatives fail. This is also one of my answers to the question of why many Agile adoptions are doomed to fail from day one.

Attempting to significantly change an organization without understanding its underlying mechanisms is simply begging for frustration and failure.

Finally, understanding the change models will influence the choice of the methods and tools we’d use to drive our change programs.

And if you chose a journey of a change agent, good luck! It can be as challenging as it can be rewarding.

February 24, 2015
Decision Making Process

I’m a strong proponent of participatory leadership model where everyone takes part in leading a team or even an organization. A part of leading is making decisions. After all if all decisions still have to be made, or at least approved, by a manager it isn’t much of participatory leadership.

(Benevolent) Dictatorship

The most typical starting point is that someone with power makes all decisions. As a result commonly seen hierarchies are just complicated structures of dictatorships. As a manager within my small kingdom I can do what I want as long as I don’t cross the line drawn by my overlord.

Of course there are managers who invite the whole team to share their input or even distribute particular decisions to team members. There are leaders who use their power for the good of their people. It may be benevolent dictatorship. It is still dictatorship though.

This model works fairly well as long as we have good leaders. Indecisiveness isn’t a super-common issue and if it is there’s at least one person who clearly is responsible. Often leaders have fair experience in their roles thus they are well-suited to make the calls they make.

The model isn’t ideal form a perspective of promoting participatory leadership. If we want more people to be more involved in leading a team or an organization we want them to make decisions. And I mean truly make decisions. Not as in “I propose to do this but I ask you, dear manager, to approve this so that responsibility is, in fact, on you.” I mean situations when team members make their calls and feel accountable for them.

I’d go even further and propose that in truly participatory leadership model team members acting as leaders would make calls that their managers wouldn’t.

This isn’t going to happen with a classic decision making process.

Consensus

A natural alternative is a consensus-driven decision making process. A situation where we look for a solution that everyone agrees on.

This one definitely allows escaping dictatorship model caveats. It doesn’t come for free though.

Looking for consensus doesn’t mean looking for the best option, but rather looking for the least controversial option. These two are very rarely synonymous. Another issue is the tiredness effect. After a long discussion people switch to “I don’t care anymore, let someone make that decision finally and move on.”

Not to mention that the whole decision making process suddenly gets really time-consuming for many people.

While in theory consensus solves accountability problem – everyone agreed to a decision – in practice the picture isn’t that rosy. If I didn’t take active part in the discussion or my objections were ignored I don’t feel like it’s my decision. Also if the decision was made by a group I will likely feel that responsibility is distributed and thus diluted.

One interesting flavor of consensus-driven decision making is when people really care about the decision even though it is controversial. It’s not that they want to avoid participation or even responsibility. It’s just consensus is unlikely, if even possible.

Such a discussion may turn into an unproductive shit storm, which doesn’t help in reaching any common solution and yet it is emotionally taxing.

Advisory Process

There is a very interesting middle ground.

My pursuit of participatory leadership decision making became a major obstacle. I declined to use my dictatorship power on many occasions encouraging people to make their own calls. The answer for a question starting with “Can I…” would simply be “Well, can you?” That worked up to some point.

It builds the right attitude, it helps to participate in leading and it makes people feel accountable. The problem starts when such a decision would affect many people. In such a case we tend to retreat back to one of the previous models: we either seek consensus or look for a dictator to make that call for us.

Not a particularly good choice.

I found the solution while looking at how no management companies deal with that challenge. Basically, everyone acts as they had dictatorship power (within constraints). However, before anyone makes their call they are obliged to consult with people who have expert knowledge on the subject as well as with those who will be affected by the

This is called advisory process. We look for an advice from those who can provide us valuable insight either because they know more about the subject or because their stakes are in play. Ultimately, a decision is made by a single person though. Interestingly enough, a decision-maker doesn’t have to take all the insight from advisory process into account. Sometimes it is not even possible.

Accountability is clearly there. Healthy level of discussion about the decisions is there as well.

Constraints

The key part of going with such decision making scheme is a clear definition of constraints. Basically, a dictator, whoever that is in a given context, gives up power for specific types of decisions.

The moment a team member makes a call that is vetoed the whole mechanism is pretty much rendered irrelevant. It suggests that people can make the decisions only as long as a manager likes them. This isn’t just a form of dictatorship but a malicious one.

These constraints may be defined in any sort of way, e.g. just a set of specific decisions or decisions that don’t incur cost beyond some limit, etc. Clarity is important as misunderstanding on that account can have exactly the same outcomes as ignoring the rules. After all if I believe I could have made a decision and it turns are not to be true I will be disappointed and disengaged. It doesn’t matter what exactly was the root cause.

Setting constraints is also a mechanism that allows smooth transition from benevolent dictatorship to a participatory model. One super difficult challenge is to learn that I, as a manager, lost control and some decisions will be made differently than I’d make them. It’s better to test how it works with safe to fail experiments before applying the new model to serious stuff.

It also addresses a potential threat of someone willing to exploit the system for their own gain.

Learning the ropes is surprisingly simple. It doesn’t force people to go too far out of their comfort zones and yet it builds a sense of leadership across the board. Finally it provides a nice option for transition from the old decision making scheme.

And the best thing of all – it is applicable on any level of organization. It can be at the very top of the company, which is what no management organizations do, but it can be done just within a team by its manager.

February 12, 2015
Economic Value of Slack Time

I ranted on 100% utilization a few years ago already. Let me add another thread to that discussion. We have a ton of everyday stories that show how brain-dead the idea of maximizing utilization is. Sometimes we can figure out how it translates to work organization as well. Interestingly, what Don Reinertsen teaches us is that queuing theory says exactly the same.

As we go up with utilization lead time or wait time goes up as well. Except the latter grows exponentially. It looks roughly like that.

But wait, does it mean that we should strive to have as low utilization as possible? I mean, after all that’s where lead times are the shortest. This doesn’t sound sensible, right?

And it doesn’t make sense indeed. Cost of waiting is only one part of this equation. The other part is cost of idle capacity. We have people doing nothing thus they don’t produce value yet they cost something. From that perspective we have two cost components: delay cost related to long lead time and cost of idle capacity related to low utilization.

Of course the steepness of the curves would differ depending on the context. The thing is that the most interesting part of the chart is the sum of the costs which, naturally, is optimal at neither end of scale.

There is some sort of economic optimum for how much a system should be utilized to work most cost efficiently. There’s very good news for us though. The cost curve is the U-curve with flat bottom. That means that we don’t need to find the ideal utilization as a few percent here or there doesn’t make a huge difference.

We’d naturally think that the optimum is rather toward the more utilized part of the scale. That’s where the interesting part of the discussion starts.

We have pretty damn good idea how much idle time or slack time costs us. This part is easy. Now, the tricky question: how much is shorter lead time worth?

Imagine yourself as a Product Owner in a funded startup providing an online service. Your competitor adds a new feature that generates quite a lot of buzz on social media. How long are you willing to wait to provide the same feature in your app? Would keeping an idle team all the time just in case you need to build something super-quickly be justified?

Now imagine that your house is on fire. How long are you willing to wait for a fire brigade? Would keeping an idle fire brigade just in case be justified?

Clearly, there are scenarios where slight differences in lead time are of huge consequences. We don’t want our emergency calls to be queued for a couple of weeks because a fire brigade or an ambulance service is heavily utilized. In other words steepness of one of the curves varies a lot.

Let’s look how different scenarios change the picture.

This sets the economically optimal utilization at very different levels. There are contexts where a lot of slack is perfectly justified. The ultimate example I can come up with are most of armies. We don’t expect them to be fully engaged in wars all the time. In fact the more slack armies have the better. Somehow we don’t come up with an idea that if an army has no war to run we better find them one.

Of course it does matter how they use their slack time, but that’s another story.

We don’t have that drastic examples of value of slack in software industry. However, we also deal with very different steepness of delay cost curve. Even if we don’t expect instant delivery we need to move quicker and quicker as everyone else does the same.

The bottom line is that our intuition about what is the cost of wait time (delay cost) is often flawed. This means that even if we are able to go beyond the myth of 100% utilization we still tend to overload our teams too much.

Oh, and if you wondered, at Lunar Logic our goal is to keep team’s utilization between 80% and 90%.

January 29, 2015
On Feedback (Again)

I’ve heard that question quite a few times after I shared my feedback with somebody: “What am I supposed to do with such feedback?”

The question may imply that feedback e.g. wasn’t “actionable” or something. Anyway, I have an answer for that. It goes:

“Whatever the hell you want.”

Yup. Exactly that. In fact this is precisely what I’d love you to do.

As the opposite to: getting defensive, explaining yourself, finding excuses, bringing other interpretations, and so on and so forth.

Feedback is not an attack. You don’t need to defend yourself. It isn’t an interrogation either. You don’t need to explain yourself. And most of all it isn’t a goddamn appraisal. You don’t need to maximize the score.

It is feedback. I’m sharing some observations and opinions that somehow relate to your work, actions, behaviors, attitude, etc.

I don’t intend to change you. I want to provide you with more information so that your decisions about your further course of action are informed better. You can disagree with the part or the whole of the message you get. You can interpret it in a vastly different way. You can confront that with other feedback that is contrary to mine. That is all just perfect. You can ignore it altogether and I’m still fine with that.

Remember? Whatever the hell you want.

The reason is I know it is subjective. No matter how much I try to make it factual it is always about interpreting facts. And I don’t try to make it purely factual. In fact, the system in knowledge work is built of people and interactions between these people. How objective can “facts” about interpersonal relationships be? Is there even an objective truth there? Or is it rather a combination of interpretations that can be more or less aligned one with the other?

So no, I’m not trying to convince you that my point is even valid. It’s how I perceive specific situation and how I feel. Oh, it isn’t factual, someone would say. Well, the fact is that I perceive and I feel so and so. Do you want to discuss with such a fact? Didn’t think so.

I am well aware that my perceptions and my feelings aren’t universal truths. That’s why it is you who decide what to do with the feedback or whether to do anything at all.

There is the other part of the story. I sometimes receive feedback and I’m like “Thank you. I’m not going to change that.” What I see as a reaction is that someone is either discouraged or even pissed off with my reaction.

I mean, they did expect me to comply with what they shared with me. I don’t differentiate here feedback on work I do from feedback on my behaviors. It’s just, for whatever reasons, I decide that I don’t want to change that specific thing.

That doesn’t make me any less grateful for feedback I got by the way.

It’s just that now we turned the tables. Now it’s: Whatever the hell I want.

If you want to make me compliant with whatever just make it explicit. At least we’ll have common understanding.

Feedback’s role, the way I perceive it, is not compliance. It is providing information about one’s behaviors, actions and attitudes and their impact. It is, as its name suggests, about feeding one back with information, not about changing one or making them doing what somebody else want them to do.

If you give me feedback with a clear intention to change me or even worse to make me do what you want you are likely to end up being disappointed.

It will happen despite the fact that I treat that feedback as factual and fair. It is factual since fact is that you think and feel whatever you think and feel. It is fair for the very same reason.

At the same time it is subjective. Objective feedback, as long as it touches interactions between people, is a mirage. Or an oxymoron. Stop pursuing objectivity. To make it clear: it doesn’t make such feedback any less valuable.

Once we understand that it enables the whole new level of discussing feedback both ways.

Ultimately it’s: “I share that with you. Do whatever the hell you want with this.”

And: “Thank you for sharing. I will do whatever the hell I want with this, indeed.”

Only then it truly is valuable feedback.

January 26, 2015
Happiness Index as Team Sustainability Metric

One of the discussions that happened during Don Reinertsen’s product development workshop was the one about absorbing turbulence. Absorbing turbulence is a metaphor for how well a team deals with unplanned variability of the process. These would be situations like arrival of a bigger batch of features to build, or especially complex work items, etc.

Normally, every team is suitable to absorb some turbulence. Beyond that point this capability will not be sufficient and the situation would quickly escalate. A good example may be that the team would gracefully deal with some additional features but above certain threshold we’ll quickly the situation escalating to a high queue state. This would result in long lead times, long feedback loops and generally decreased responsiveness of a team.

These all result in lower efficiency too.

If such a situation persists over longer period of time it can take a heavy toll on people as we are running at risk of burning people out.

I really like the analogy that Don uses in his work: when a human body is losing blood, interestingly enough, blood pressure doesn’t go down. What our body is designed for is to pump enough blood to the brain so it can operate normally.

To compensate for losing blood the heart rate keeps going up. It goes up to the point where this mechanism is no longer sufficient and the organism crashes over a very short period of time.

A similar thing happens when we overload our teams. For some time they deal with the overload just fine introducing their own coping mechanism. They’d likely work overtime, introduce additional multitasking, etc. A problem is that, similarly to the situation when a human body loses blood, there’s a price to be paid for that.

Eventually people end up burned out and leave an organization. From that perspective a good question would be: what kind of early signals we get so that we can address the problem early.

One answer would be careful monitoring of work. How much work in progress we have. How our queues in backlog change. This kind of stuff. While obviously that would provide us some signal, that wouldn’t really be a proxy measure if we want to consider people first, not the process first.

What strikes me is that we at Lunar Logic already use a nice signaling mechanism that would give us an early warning. The mechanism is a happiness chart. Despite the fact that a happiness chart is a super simple, super low-tech tool it works on a few levels.

On one level we have individuals. When I see a deviation from the norm in the chart of one person it likely means that something’s going wrong. It may be related to the work, it may be related to a personal life. Whatever the case is it does affect the work.

If the case is individual it will unlikely be related to the whole project.

Another context is the one of the whole company. If things were going generally wrong I’d expect to see a strong signal across the whole board. “Generally wrong” may mean either mediocre business results, or a cultural problem, or a strong source of frustration, or a bunch of different things.

In such situation the signal would be broader than just a single project or product team.

There’s another scenario, which would be a bunch of people recording worse than typical mood and the correlation would be around a common project. Process-related parameters of that project may look OK: a backlog queue wouldn’t grow, throughput would go up, etc. Is there anything wrong then?

In this case happiness chart would serve as blood pressure – it would be a countermeasure pointing that something is going not exactly OK and if we keep doing that we may end up crashing.

The rule for our happiness chart is that the color translates to the mood. Green means happy, blue means so-so, and red means not happy. Once the chart for a project team gets more bluish or even reddish that’s a very strong indicator that we are not absorbing turbulence in that team gracefully.

The interesting part is that a happiness chart would provide such an information no matter whether a root cause is overloading a team with tasks, interpersonal conflicts that affect collaboration or anything else. The alarm would go off in either case. That’s actually perfect as we want to react to dangerous turbulence early in any situation.

From that perspective the outcome of happiness chart isn’t a leading indicator per se – when the change is triggered it means that there’s already something happening. It isn’t a lagging one either. We can correlate it with other parameters or even check with people to figure out what is happening. We would know that we’re not coping with turbulence well enough much earlier than when we are on the verge of crashing.

The reason why I think this strategy is so valuable is because it allows to merge the data from two different universes. On one hand we have all the process metrics that tell us how we are doing from efficiency perspective. On the other we get a social metric that tell a lot whether the current state is sustainable.

It is exactly like a combination of a blood pressure and a heart rate. The former translate to efficient work of our steering center – the brain. The latter tells a little bit how sustainable current conditions are.

November 24, 2014
Two Rules of Autonomy

One thing that we are doing at Lunar Logic is we evolve toward no management model of leadership. This means a lot of small changes that all happen with the same attitude at heart: to distribute more and more decision-making power across the whole company. This by the way also means systematically stripping down the management from that power.

The latter is easy in our case as the management is limited to me and I kind of launched the whole process. I would have to be either a hypocrite or a schizophrenic to resist the changes. Luckily enough I believe I’m neither. (Unless that other me has something else to say, that is.)

I don’t say it’s easy. One challenge in each step toward participatory leadership is that we, humans, don’t like to give up on power. I’m no different. I like that warm feeling that I can make a call and it shall be as I say. It’s not only that. Sometimes I simply know which option is good and the temptation to intervene and tell people what’s the best choice is strong. It would mean, however, taking a step back on a path toward democratizing leadership. So I keep my mouth shut.

On other occasions I just feel like we are going too far from my comfort zone and I slow down the process.

Giving up on power is a prerequisite to go further. While I don’t say it will go as easy in every case it isn’t enough to get that part working. In fact, despite being vocal how much I don’t want to make all sorts of decisions and how much I appreciate autonomy I still get loads of the questions that start with “Can I…”

If I’m lucky enough to suppress my System 1 reaction that would be either of: yes, yes but, no, no but answers I’d reply with “Can you?” The ball is back in your court and as long as you take responsibility for the call you make I’m OK with that.

The interesting thing is why these questions are popping up over and over again though. Despite the fact that on a conscious level we promote autonomy our natural behaviors means retreating back to the old pattern of asking for permission.

We simply don’t claim autonomy even if it slaps us in the face.

Besides years of programming our brains by education and work system that make it hard to act differently there’s another reason for that. Most of us want to be good citizens and we don’t want to use our autonomy to do stuff other wouldn’t like or even would be against. So we back up to the ultimate decision-making authority who is supposed to know what everyone in an organization likes or approves or more likely who doesn’t give a damn what anyone thinks – a manager.

The interesting thing is that the fear sometimes is well-grounded. We have different sensitivity toward different things. Behaviors that we consider positive or neutral may have negative connotation for others. If I’m a manager and I use my ultimate decision-making power and I don’t give a damn then, well, I don’t give a damn. But what if I’m just a team member who cares?

The idea we came up with is a set of two very simple rules.

1. The Nike Way
If you want to do something just do it.

2. Speak Up
If you don’t like what someone else is doing speak up.

Yes, that’s it. There’s one underlying principle, which is mutual respect. We don’t need to love each other. We need to respect our autonomy and our right to have different views on stuff.

The nice thing about this setup is that it is a self-balancing mechanism. It takes only one person try something new. It doesn’t require permission or even extensive up-front discussion. Pretty much the opposite, as a default we assume that every initiative would be awesome and everyone would love it or at least have nothing against.

The Nike Way is verbalizing the attitude described by famous Grace Hopper’s words: It’s easier to ask forgiveness than it is to get permission.

What we do know is that despite best intentions it won’t be true all the time. Occasionally, OK more often than occasionally, someone would do something that somebody else is not OK with. Then we have Speak Up rule that triggers a conscious and meaningful discussion (sometimes dubbed a shit storm) that provides additional insight for both sides and most likely some sort of consensus.

Speak Up rule was designed with a positive scenario in mind, i.e. someone unintentionally stepped on someone else’s toe. It works however in malicious cases as well. When someone intentionally crosses the line or pulls an organization in an unwanted direction someone else will speak up too.

The best part is that the same way it takes only one person to just do it, you need only one person to speak up.

One might point that there’s a risk that it would end up in indecisiveness. So far I don’t see that happening. First, speaking up doesn’t mean the ultimate veto power. It simply triggers a discussion. Second, the respect bit that is a hard prerequisite keeps the discussion civilized.

There’s a little more sophistication to balance that. Naturally extroverts would have an upper hand in unstructured discussion. That’s where empathy plays its role as helps to facilitate these weaker signals. On a basic level there are just these two simple rules: The Nike Way and Speak Up rule.

November 17, 2014
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.

August 11, 2014
(Don’t) Change Your Job

Few of us have comfort not to worry, or think, of changing a job ever again. If you’re not one of those few, this post is for you.

I have easily gone through way more than a hundred of exit interviews. No, it doesn’t mean that I changed job that many times. This means that so many people left my teams. Nothing to brag about, I guess. Anyway, if there’s a reason for leaving one’s job I’ve heard it. And I’ve heard it from a person who I knew and worked with for quite a while.

Obviously, more often than not I tried hard to keep people around and missed those who decided to leave. This wouldn’t make me an objective adviser at a time. However, from a perspective of time, once what had been about to happen already happened, I believe I can go beyond emotions and biases and be pretty objective.

There’s one thing that I noticed in my attitude when I talk to people about leaving. I feel and act differently when I try to keep on board someone who I believe may be making a good decision than in cases when I’m pretty sure they are making a mistake. While I don’t think any of you would find my feelings even mildly amusing, what is interesting is that my compass seems to be working surprisingly well.

So how the hell do I sense whether changing a job is a good idea or not?

It’s pretty much one thing. What’s more it sounds obvious. Surprisingly enough people very rarely follow the hunch.

It’s all about how values of an organization one is about to join are aligned with their own values.

Yup, that’s it.

I mean, seriously. Ask people what they value. It’s an individual thing so they’d come up with all sorts of stuff, like respect, safety, trust, transparency, challenges, health, happiness, authenticity, quality, learning, perspectives and whatnot. Interestingly, very, very few people I know would say “more money” and in such cases they’d likely have pretty good reason for that (which is fair enough too).

A nice thing is we can get pretty good hints whether these values are respected and embraced at our workplaces-to-be.

“You can’t know” one would say. Well, you can. It’s enough to realize one thing. Every publicly or semi-publicly known action of a company is emanation of how it operates inside. In other words if you want to know what is valued in any given org just pay attention to how that company acts publicly.

Are they worth of trust as a business partner? Why should they be as an employer? Do they care about well-being of their clients? Why should they care about yours? Do they respect any partner they work with? If not, why would you assume their respect would be extended to employees?

I don’t say that without a reason. It’s not a rare occasion when there’s a value match or at least there’s nothing that would indicate the opposite. At the same time I’ve seen way too many bad decisions ignoring the obvious hints. As you may guess it didn’t work very well.

So here’s my advice: ask yourself what is important for you. If an employer-to-be shares the key values with you then go for it. And yes, I do understand that I actually may be encouraging some of my people to look for alternatives. I don’t mind. After all, if I consider myself a leader I should care about well-being of my team, shouldn’t I?

At the same time if your employer-to-be doesn’t seem to share your values this is a single most powerful signal to take into consideration. It means that the whole setup would suck eventually.

And yes, it’s enough to look at, or ask about, relationships with partners or clients.

It’s all about values and you can’t lie about values. If you are fair to your partners you’re going to be fair to your employees. And vice versa.

Few people would take consider it when thinking about changing a job. Don’t be one of them.

March 19, 2014
No Management Mindset

All sort of no management approaches are hot these days. It shouldn’t come as a surprise. Self-organization, empowerment and autonomy are inherent parts of Agile and Lean approaches. If you distill the essence of these and bring them up in the hierarchy it means quite a challenge for traditional ways of managing teams.

Of course, few organizations are that far with their evolution and only handful, like Semco, Valve or (recently) Zappos, are really radical with no management. I’m not an orthodox though. I’m not going to draw a line that separates no management organizations from regular ones. I don’t see a point and I don’t care about labels anyway.

The important part here is mindset – understanding why you are changing the approach to management and what expect to achieve with that.

And honestly, I don’t expect us to see no management approach becoming a new trend in organizing companies, no matter how vocal its proponents are. There are a few reasons for that.

We are so strongly rooted in traditional approach to management that I don’t expect many would find it easy to change their mindset. And they don’t need to. We may take pretty much whatever reasonable organization’s success criteria you want. Then, basing on the criteria we’ll find the most successful companies in the world. I’m almost sure that the top ones would be those with pretty traditional management approach.

Of course statistics are against no management organization. I mean, there are only that many of them. However, if no management was so superior we should have loads of wildly successful followers. Sorry, that’s not what I see.

The reason why I don’t see a rapid adoption of no management is that it is damn hard to make it work. And it’s way harder to make it work at scale. I would say that fixing dysfunctional management of an organization without changing the whole approach to management as a whole is a task that is an order of magnitude easier than a transition to no management.

By the way, when we cease to have formalized management we flip one of systems thinking paradigms. In fact, no management means magnifying the fallacy of people versus system dichotomy. Suddenly we can’t just blame the system as everyone explicitly co-creates that system.

A simple example. It happens so often that people delegate decisions and responsibility at a workplace asking “can I…?” Obviously, each “yes” or “no” answer, besides addressing a question, sets a constraint. This is allowed here and that isn’t. By the way, that’s how we define system at our organizations.

What if there’s no definite answer? Or the only answer is that here are our high-level goals and everyone makes their own decisions so we get closer to achieving these goals? Everyone makes their own yes / no decisions and thus get involved in setting constraints. Everyone is, in fact, involved in defining and designing the system.

The interesting part is that all it takes to get there is management distributing their power across the whole team instead of executing it.

You don’t have to get rid of the management. You don’t have to become one of those hot no management organizations. It’s just a mindset change.

This is also a reason for a very limited adoption of no management approaches. A mindset change only sounds simple. It goes against almost everything that we’ve learned about leading teams. Usually it goes against team’s expectations too. Even more so when people visualize scenarios taken from Zappos or Valve or W.L. Gore.

There’s a good part too. If we are talking about mindset it means that it is applicable in all sorts of environments. You don’t have to be a full-blown no management organization to do this. You can push the limits pretty far with your team, even if you are a part of an organization that adopts more traditional way of managing teams.

All it takes is to give up on power while still taking responsibility. Would you dare?

February 17, 2014
The Fallacy of the Ideal Team Size

An argument over the best team size is as active as ever. As long as we are in broadly understood context of agile the starting point usually is 7 plus or minus 2 people, which was widely popularized along with Scrum. This, by the way, leaves pretty wide margin for the optimal team size. You can find more precise answers though.

It may be 6.

My rule of thumb is that no work team should have membership in the double digits (and my preferred size is six), since our research has shown that the number of performance problems a team encounters increases exponentially as team size increases.

J. Richard Hackman

Or maybe it is 4.6. By the way, does it mean that we need part-timers to chase the ideal? Oh well…

For the contrast Larry Maccherone reported at Lean Kanban North America 2013 that his quantitative research on data from nearly 10,000 teams showed that there’s no difference in productivity and quality in teams of 5-9 people and those of 10-12 people.

Yet another argument to the discussion: Anita Woolley’s research shows that collective intelligence, which I find a key ingredient of team effectiveness, raises along with a team size. It flattens out between 10 and 11 people.

But wait, didn’t Fred Brooks in his classic Mythical Man Month taught us that along with team size growth a number of communication paths grows exponentially? That would mean that for a team size the bigger means the worse.

This is confusing, isn’t it?

We are talking about the range between 4 and 12 already. I guess it wouldn’t take much of research to find sources that would broaden that range even more.

The tricky part, and one that often go unnoticed, is that when discussing the perfect team size we don’t ask the question: perfect for what?

Each of aforementioned sources focuses on a different angle. Be it performance issues, decision making, quality, productivity, problem solving or communication. Would optimizing any single one of these make a perfect team? I doubt it. Is it possible to optimize all of them at the same time? Well, it seems pretty unlikely. The numbers are just too far one from the other.

That’s not the fallacy of the perfect team size though. I know I’ve just introduced a complex equation with many variables to solve the ideal size problem. However, knowing our specific context we can use different weights for different parameters and solve the puzzle. Oh yes, it would be super-contextual and probably would be very hard to copy even for another team within the same organization. It doesn’t really matter though as the effort would be futile.

It doesn’t matter because the whole discussion is flawed unless we understand how our teams operate. While we typically assume that structural or hierarchical borders are what constitute a team it is a huge oversimplification.

An interesting thing happens when we observe organizations without fixed teams. One example may be Lunar Logic where people are assigned to ephemeral project teams and when a project is finished they move on to a next challenge. Another example may be Valve where someone who has an idea looks for others who are willing to develop the idea with them. These teams are even more unstructured as, at least in theory, people can come and go as they want.

Now, let’s think for a while how people work in such environments. Do they function only within a team they are currently a part of? To some point. As long as a discussion is related strictly to the matter of a project they likely keep it within a project team. However, given that the borders aren’t that strict it’s much easier to go beyond a team to look for new ideas or solutions when an issue is more general.

In other words people function in at least two different teams depending on a context. In Lunar, if I have 3 people in a project team this would be one entity they are part of. Another one would be 7 people who sit in the same room. Yet another one would be everyone within a range of a shout which is pretty much everyone in the company (yes, I know it’s easier with a small organization).

Depending on a specific situation people would organize themselves to optimize a key parameter to accomplish a task. When they are discussing the scope of new batch of work they would go to an empty room to optimize communication and focus. When they are solving issues they would have an open discussion and likely invite people from other projects to improve creativity and collective intelligence. When they want to make sure the quality stays high, they’d look for another pair (or pairs) of eyeballs to look at the code as very small teams seem to have worse quality than bigger ones.

Now, a big question: what team size we are talking about here actually?

Well, I told you. Three people. Except, when you look at a broader context, it isn’t much of answer, is it?

By the way in the context of Lunar Logic whenever I’m talking of teams I like to think of two layers of teams. One is a project team which typically is small. Two or three people per team aren’t a rare situation. Another layer is the company as a whole. In many cases we act as one big team. No hierarchy whatsoever of course helps a lot but that’s a different story. It means that we flexibly operate in 2-25 range in terms of a team size. I bet the ideal size, whatever it might be, is within this range.

Of course, an unstructured environment makes it easier to break the hierarchical borders. However, even in pretty structured organizations I know I see the same behaviors, except they are not that intensive.

The fallacy of ideal team size is that there is no such thing as the ideal team size. Instead of organizing people according to some sort of a magic number we should rather think of how to create an environment where people can easily adjust that size by themselves depending on the context.

Then the whole discussion of what’s the best size will simply be irrelevant.

January 28, 2014