Pawel Brodzinski on Leadership in Technology

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

Category: team management

What LEGO Can Teach Us about Autonomy and Engagement
Last time, I built the connection between distributed autonomy (or lack thereof) and engagement (or lack thereof). Admittedly, I drew from different sources, and one could question some claims or connections I made.
- I mix engagement and motivation, and they are not simple substitutes for one another.
- Gallup’s State of the Global Workplace has faced some criticism for not actually asking about engagement, but instead inferring it (by the way, this book explains the methodology behind the research).
- We all have anecdotal stories about limited-autonomy environments where engagement doesn’t seem to be a problem.
So how is it, really? Do we really feel more engaged when we have more control over the work we do?

I have the privilege of running the course on progressive organizations in all sorts of settings, from MBA programs, through postgraduate studies, to professional training. As a part of the course, I designed a little experiment to run with all those different crowds. Over the years and across contexts, it keeps telling the same story.

What Can LEGO Teach Us About Autonomy?

The experiment is fairly simple. I get a group of people to build a relatively simple LEGO set. Twice.

The Managed Build

The first run is well-organized. We pick one team member as a manager, who starts by assigning tasks to the rest of the team. A typical team member’s job would be to:
- Be responsible for a specific type or color of pieces.
- Build a particular part of the model.
- Etc.
Over the years, I experimented with how much freedom a group’s manager has in organizing work. It doesn’t seem to matter. What’s important here is that the whole work organization is designed by—and, to a degree, enforced by—a single person.

Then they get to build a catamaran. With instructions. Displayed on a screen. With me controlling the pace. Actually, it’s they who control the pace. I “flip” the page once the last team is ready.

Eventually, all the teams build perfect catamarans. Up to specs. There are some subtle challenges in the process, but that goes beyond the context of autonomy versus engagement.

The Self-Organized Build

The second run is different. There aren’t managers anymore. There is no task assignment pre-building. The whole instruction is: “Self-organize.”

There is no instruction either. The only thing a group gets is the picture of a hydroplane they’re building.

People have all the freedom to organize their work. Sometimes they do plan. Much more often, they don’t. A creative and messy process commences. Inevitably, it’s all louder and more chaotic than the first run. On average, it’s a bit longer, too.

Eventually, I get my hydroplanes. Some of them perfect. Others not so. However, I’m yet to receive one that differs from the picture in anything other than minor details.

The Lesson

While there are many facets to this experiment, the big lesson is about engagement. After each run, I ask everyone individually to assess their engagement during the task on a scale from 1 to 5:
1. Very low
2. Rather low
3. Neither low nor high
4. Rather high
5. Very high
The underlying hypothesis is, of course, that the second run, the one where people have more autonomy, yields better engagement.

Across all the teams that have ever participated in the exercise, the current running averages are:
- 3.24 for the managed build
- 3.94 for the self-organized build
There wasn’t a single experiment in which teams were less engaged in the second run (though in one case the results were close—0.14 difference).

In other words, I’m yet to see a group of people who would be less engaged in a creative LEGO build when they were given more autonomy.

Some Experiment Caveats

One important aspect of the experiment design is that the models are relatively simple, while I organize people in groups of 4 or 5. As a result, there are too many hands for the task. It is so by design. It’s an environment where it’s relatively easy for people to disconnect, should they choose to.

Also, it’s LEGO. For some people, it will be inherently engaging no matter what. They tend to take an active part in the first run, disregarding their assigned role.

Those two aspects of the game create an environment in which people use the full scale when assessing their engagement. I’ve only had one group that hasn’t used 1s at all. Possibly too many AFOLs in the room.

The pace of flipping the instruction pages in the managed build tends to be a minor source of frustration for faster teams. Again, that’s by design. It’s just another dimension of limited autonomy. After all, with real work, we have all sorts of interdependencies.

A side note: Interestingly, it’s not always the same team that is the slowest throughout the whole run. It’s a classic case of a shifting bottleneck.

Distributed Autonomy Is a Crucial Prerequisite for Engagement

My working hypothesis is that the main reason behind appalling engagement levels is limited autonomy. The theory suggests as much.

Source: Gallup’s State of the Global Workplace

The LEGO experiment is a neat way to confirm that in practice. With a simple change of giving people more autonomy, the declared engagement goes up by more than 20%.

The observable behaviors are different, too. The managed build generates way less energy, fewer discussions in teams, less movement across the room. If you saw randomized silent movies (no audio) from the respective experiment runs, it would be obvious which is which.

Distributed autonomy—being able to decide how we work—is an absolutely crucial aspect of our workplaces. And a prerequisite for high motivation and engagement.

This is part of a short series of essays on autonomy and how it relates to other aspects of the modern workplace. Published so far:
I’m writing these posts by hand. Like an animal.
웃https://okhuman.com/NbZHoQ
January 28, 2026
Radical Candor Is an Unreliable Feedback Model
Sharing good-quality feedback is one of those never-ending topics that we simply can’t get right, no matter how hard we try. We’d try things, exchange best practices, and… have the same discussion again, 2 years down the line.

I remember rolling my eyes at a trainer two decades back when they tried to teach us the feedback sandwich. In the early 2010s, Nonviolent Communication (NVC) was all over the place. Then there was a range of methods inspired by active listening. Finally, Radical Candor has arrived as a new take. A wave of fresh air was that it didn’t focus so much on the form, but more on what’s behind.

I wish I could refer to a single method, tell you “do this,” and call it a day. In fact, when challenged to share what is a better option, I don’t have a universal answer. Not much, at least, that goes beyond “it depends on the context.”

If there’s something that I found (almost) universally applicable, it is to share any feedback in a just-in-time manner. The shorter the feedback loop, the better.

Yet, of course, there is a caveat to that as well. Both parties need to have mental capabilities to be there. Sometimes, especially when hard things happen, we aren’t in a state when this is true, and we’d better defer a feedback session to a later point.

Also, it doesn’t say a thing about the form.

Radical Candor

Kim Scott’s Radical Candor is continuously one of the most frequent references when we discuss feedback. Its radicalness stems from the fact that it abandons being nice as a desired behavior and advises direct confrontation.

In short, as a person delivering feedback, we want to be in a place where we personally care about the other person and we challenge them directly. No beating around the bush, sweet words, or avoiding hard truths.

Caring personally is the key, as it builds this shared platform where we can exchange even harsh observations and they will be received openly. After all, the other person cares.

The other part—challenging directly—is more straightforward. We want to get the message through, leaving little space for misinterpretation, especially when feedback is critical.

Do We Personally Care?

Out of the two dimensions, the directness of a challenge is the easier one to manage. We can pre-prepare feedback so that it goes straight to where we want it to land. This way, we avoid ruinous empathy territory.

The caring part, though? How do we figure out whether we care enough that our message will be radical candor and not obnoxious aggression? How do we know that we are here and not there?

I’m tempted to say that we should know the answer instantly. After all, it’s our care. Who’s there to understand it better than ourselves? I’m teasing you, though.

Figuring it out in front of the mirror will often be difficult. More so in environments where care is not a critical part of organizational culture, and thus, does not come up easily.

Then, it’s not just about whether we care or not. It’s as much about whether we are able to show it.

A simple advice would be to show as much care as we reasonably can. We bring that dot up as much as we can, and things should be good, right? Oh, if only it were that simple.

Feedback: Radical Candor or Obnoxious Aggression

Some time ago, I was talking to one of our developers, who was complaining about another person. The other person had asked questions/challenging the developer about relatively sensitive matters.

Then, it struck me.

“OK, I remember myself making exactly the same remarks and asking exactly the same questions. Does it mean that I have offended you, too?” I asked, upon realizing that at least in one case, my behavior was a carbon copy of the other person’s.

From the response, I learned that I was OK. The other person was not. Why? “Because you care and [the other person] does not.”

In other words, I was in a safe space of radical candor, and the other person was way down in the obnoxious aggression territory. Except we were precisely in the same spot (same behaviors, same remarks).

The whole situation was all about how the said developer interpreted specific situations and how much goodwill and leeway they gave me and the other person.

Where Are the Lines?

The story clearly shows that we can’t fix the lines in place in the Radical Candor model. It’s not a simple chart with four quadrants, where we necessarily want to aim for the upper right corner.

The borders between the domains in the model will move. They will be blurry at times. And, by no means, will they be straight lines. If we tried to sketch a model for an actual person, it would look way messier.

There will be areas where we’re more open to a direct confrontation, and those that are way more sensitive.

Take me as an example. I tend to consider myself a person who’s open to critique (and I’ve done some radical experiments on myself on that account).

I’m fine if you question my skills, judgment, or the outcomes of my actions. Not that it’s easy, but I’m fine. But question my care? That’s a vulnerable place for me, and you’d better be less direct if that’s what you’re about to do.

To make things worse, the picture will be different depending on who is on the other side. For a person I deeply trust and respect, the green area will dominate the chart. For another, where neither trust nor respect is there, the green space may be just in a tiny upper right corner.

And if that wasn’t enough, it changes over time. We have better days and worse days. We have all other stuff to deal with, stress, personal issues, and all those things conspire to mess with the Radical Candor clean chart even more.

“Fuck off” Coming From a Place of Love

During my first weeks at Lunar Lugic, one of the youngest developers at the company told me, in front of a big group, that “I acted like a dick.” It was his reflex response to something I did, which I can’t even remember now. Nor can he.

The next day, he came to the office with a cardboard box to pack his things, ready to be fired for offending the newly hired CEO. Little did he know that:
- I was grateful for his timely remark
- I appreciated his courage
- I couldn’t care less about the form
Even if none of the common advice would suggest that, for me, it was indeed a quality bit of feedback. And the developer? He stayed with us for more than a decade. And he definitely didn’t need that cardboard box.

His challenge was direct and blunt. Did he care about me personally, though? No. Did it change anything for me? No, not really. For me, the remark has still landed well in the radical candor territory.

As a metaphor, I have some people in my life whom I can tell to fuck off. Or vice versa. And that “fuck off” would come from a place of love. The form, while harsh, is something that bothers neither me nor them. After the shots have been fired, we will laugh and hug.

I bet you have such people in your life, too. Those who have seen the best and the worst of you and decided to stick with you, nevertheless. People you trust and who trust you. You respect them, and they return the favor.

Send the same “fuck off” to a random colleague and you’re neck-deep in obnoxious aggression, no safety guardrails whatsoever. Although, in this case, it should instead be called obnoxious violence. No amount of personal care can fix this.

Radical Candor Is an Unreliable Feedback Frame

As a theoretical model, Radical Candor is neat. I really like a cross-section of personal care and direct challenge as a navigation tool in communication.

However, it creates an illusion of precision while pushing us more toward unfiltered, well, candor. This combination is harmful more frequently than just occasionally.

We can figure out (roughly, at least) where our message is on the diagram. The big problem is that we’re mostly clueless about where the lines are.

In fact, we have good insight into the borders between the domains only after we have established a pretty good relationship. Which is precisely when we need the least awareness about the exact line position.

In a typical case, we’d be shooting in the dark. Even if we understand the form and the content of feedback we share, it may lead us to a very different place than we expect. Many of the reasons why are beyond our sphere of control.

Feedback Instruction Manual

I’d be reluctant to adopt Radical Candor as my go-to feedback frame. However, if someone comes to me and says that’s what they expect, I’m happy to oblige.

That’s a good trick, by the way. As a person who wants to receive more feedback (don’t we all?), tell people how to do it in your case.

For example, I prefer criticism to praise. The latter sure feels good, but it does little in helping me improve. I’d rather feel awful for a while and get better afterwards than the reverse.

I appreciate challenges. Which doesn’t mean that I’m quick to admit I was wrong. I need time to rethink my position. So, if you want such an outcome, give me that time.

And I could go on. But this is my instruction manual. I don’t expect it to work for anyone else automatically.

The same is true when you are on the sharing end. Be explicit about your intentions. I routinely start or finish (or start and finish) giving feedback with the following remark:

The first rule of feedback applies: Do whatever the hell you want with it.

Save for some edge cases, I never have any explicit expectations for a change. When I share, it’s just this—sharing.

Being explicit about your intent will do way more than following any fancy model.

This post has been inspired by the conversation with Lynoure Braakman on Bluesky. Thank you, Lynoure, for the insightful remarks and the inspiration.
August 21, 2025
Autonomy and Transparency: Both or Neither

How does transparency feel? Early in my career, I had an occasion to experience that. I was working in a typical organization where lots of things, payroll included, were secrets. Then the salary list leaked out. It wasn’t a huge leak, i.e. it didn’t go public, but I was close enough to the source that I could take a look.

When I was about to open the spreadsheet with the data, I was thinking about my expectations. I hoped that information about salaries would help me to make sense of how people in the company are perceived by the leaders. I thought that it might provide me with role models to look up to. I was ultimately looking forward to transforming new knowledge into some inspiration and motivation for myself.

That was totally not what happened.

What I saw on the payroll was a lot of unfairness. I saw numbers I couldn’t possibly justify. I couldn’t make sense of the system that produced these numbers. Most of all, I was painfully aware that there was literally nothing I could do to change that. After all, I shouldn’t have seen the data in the first place.

Ultimately, I got frustrated.

Transparency without Autonomy

With the benefit of hindsight, I see a broader picture of that experience. On one hand, I am aware that back then I couldn’t have had the whole perspective on what was valued in the organization and thus my sense of unfairness might have been exaggerated. I didn’t have insight on systems thinking to be able to rationalize the shape of the payroll as a pragmatically predictable outcome. Should I understand that my outrage and my frustration wouldn’t be that big.

The bottom line remains the same. I should have been expecting frustration as the only logical outcome of such an experiment. I put myself in a situation when I was about to get access to data that was important to me on an emotional level and yet I knew I had no influence whatsoever on shaping the future state of that data.

I got transparency with no autonomy to act. Heck, I couldn’t even ask all my “whys” to better understand what was going on. I put myself in a position where my frustration was guaranteed.

Transparency without autonomy is a recipe for frustration.

It’s like telling people stuff that they don’t like, or agree with, and then telling them to live with it. You don’t like who gets a raise? Live with it. You don’t agree with who gets promoted? Live with it. You don’t agree with disparities on the payroll? Live with it. You get the idea.

A side note: I refer to autonomy and not authority. There’s a significant difference between the two. For the sake of this discussion, the crucial part is autonomy defined as the actual use of decision-making power, not just the availability of decision-making power.

Autonomy without Transparency

What about the opposite situation? Can we let people act while keeping them from accessing sensitive data? The answer to this case is rather obvious, I think. Acting in an organizational context means making decisions. Can we then make decisions with limited access to relevant information?

Yes, we can. The question is: would that be good decision-making? Even though a common perception that more information available to a decision maker would result in a better decision is a myth, it is still crucial to have access to a few most important bits of data.

In our context most important often translates to most sensitive and thus available to few. If we let people decide without making such information accessible we’d set them up to fail. Their decisions simply won’t be informed and thus random and low quality.

Decentralizing control requires decentralizing both the authority to make decisions and the information required to make these decisions correctly.

Don Reinertsen

To stick with the original example, just try to imagine people deciding on raises without knowing what salaries are.

Transparency and Autonomy

OK, so neither autonomy nor transparency alone does make sense. What does, then? If we aim to improve either one we need to think about both at the same time.

Each time we loosen transparency constraints we should answer: how can people act on newly accessible data? What will they be able to do if they aren’t satisfied with what they see? The answer doesn’t have to be full control over changing the part of reality that we’ve just made transparent. They do need to have influence, though.

When we were making salaries transparent at Lunar Logic we didn’t give people the power to set the salaries. Well, not initially. We gave them as much as, and as little as, influence: an option to start a discussion about a salary and space to share their opinions about any raise under discussion. Even if the final decisions were still being made by the same person as before the change there were clear options anyone could exploit if they were dissatisfied with any number on the payroll.

While eventually influence has transformed into full control over decisions, the key move was the initial one. The one that gave people influence.

The guidance is much more straightforward if we start with the intention of extending autonomy. We simply need to answer what information we consider when making this kind of decision and then make that information available.

Most often the hard part is realizing what range of information we really consider. When we started experimenting with the decision-making process at Lunar Logic, the first step was to let people spend company money without asking permission. The part of the process was, and still is, what we call the advisory process.

As a part of advisory processes, I was often consulted about planned expenses. The most important lesson for me from the advisory processes was how unaware I was of all the data, experience and mental models I was using when I was making decisions myself. This, in turn, made me realize how much more transparent with all these we need to become to get autonomy working. A simple example: if we want people to spend company money wisely they should know what’s the financial health of the company and how specific expenses may affect it, i.e. regular financial reports should be available to everyone.

Moving the Bar

The bottom line is this: when we raise the bar of transparency we need to raise the bar of autonomy as well. And vice versa.

It is not as obvious as it sounds. Each change fuels and influences another. It is more of a balancing act than a prescribed set of moves one could repeat in every situation.

There is a caveat too. Transparency is a one-way street. You simply can’t undo making salaries transparent. You can’t make people unsee the payroll. Then again, transparency doesn’t go alone. It must be followed by autonomy. This means that changes on both accounts are almost impossible to reverse.

In fact, rolling autonomy back is a bad idea not only because it is connected to transparency. Even if we looked at autonomy in isolation there’s a painful penalty to pay for removing autonomy that has already been granted. It is an equivalent of saying “we weren’t serious in the first place about giving you that power”. Not only we are back to the square one but also people would be discouraged to embrace autonomy in the future because they got burned.

The obvious advice in this context would be to tread carefully and to take one’s time. We will find ourselves in a place where we feel like we took a step to far. What we can do is to take a break until we learn how to embrace the new situation.

At Lunar Logic it happened sometime after we made salaries transparent and gave people influence over raise decisions. Suddenly we found ourselves in the middle of what we now call the raise spree–a lot of raises were happening simultaneously with little consideration of their ripple effects. Instead of removing autonomy or double guessing individual decisions, which would end up the same, we focused on educating ourselves. How individual raises would influence other decisions about salaries and the overall financial condition of the company. Only as soon as we felt comfortable with the autonomy we had we moved the needle again.

Neither or Both?

If we stick to the assumption that increasing autonomy and transparency should go together, the question we should ask is: should we even bother? If it’s the choice between both and none, why not to choose none and stick with the status quo?

The younger version of me would say that more transparency is always better than less. Well, now I would argue with my younger self. There are edge cases, like the one that I started with. However, in general, I believe that it is easier to lead a company when more information is available to everyone. At least in a part, it comes from a fact that not only is it more transparency, but also more autonomy. The latter releases a part of the burden of people in leadership roles.

I do have a better answer when it comes to autonomy. Dan Pink points autonomy as one of the crucial factors that our motivation depends on. Little autonomy, little motivation, he says. Given how discouraged autonomy is the modern workplace we can only do good if we pursue it more. It won’t happen unless we care about autonomy and transparency together.

For me the answer is obvious. It’s both; not neither. As difficult as the evolution can be, it’s worth it.

April 17, 2019
Agile Self-Organization: Band-Aid for a Broken Leg

One of the concepts that has been widely popularized by Agile movement is self-organization of teams. It lands very nicely in any Agile context, no matter the discussed method or even a general approach one might have to Agile implementations.

It is, after all, an idea that appeals to line employees and managers alike. Let’s give atomic teams power to decide how they would work within safe constraints. Safe here means safe for managers, of course. In one swift move we address, at least to some point, two issues. One, we increase empowerment across team members as they get more say over how they work. Two, we remove managerial burden of work organization at a the most detailed level, at which managers’ competence can frequently be challenged.

All but the most micromanagerial types should be satisfied.

Since how the work gets done is decided closer to where it actually gets done, we increase odds of good processes and policies. At the same time, through more autonomy we improve motivation and engagement.

It’s not without a reason that self-organization at a team level got its way into common practice.

History of Agile (Oversimplified)

The starting point for self-organization as a technique or a practice is not unlike other agile practices. Early Agile methods were focused on a team. The perspective might have differed, but the atomic entity in consideration was always a team. Be it Scrum, XP, Kanban or anything else, in their early forms there was little mention on interoperability across teams either horizontally or vertically.

Obviously, once Agile got traction there was a need for scaling the approach up. Initially, some makeshift approaches were being made to do that (anyone remembers Scrum of Scrums?). Eventually, whole methods were built to enable large scale Agile implementations—SAFes and LeSSes of this world.

These approaches were built around a core method, typically Scrum, and took good parts of other methods whenever authors saw fit. Fundamentally, the value added of these methods was in a description how to roll everything out in a big organization. The desired outcome would be to see the core method implemented in multiple teams while ensuring some level of alignment across an organization.

It was about scaling up the method and not scaling up the principles behind. It was about getting more Scrum / Kanban / whatever teams in an organization and not figuring out how the basic values and principles would have to work if they were applied on different levels of an organization.

That’s exactly when we petrified self-organization as a technique relevant to a team and a team only.

The Broken Leg

Let’s look at the problem we are solving with self-organization. We give people autonomy and they organize work better as they are most knowledgeable how the work can be done optimally. At the same time, since we distribute autonomy, we increase motivation and engagement.

So far, so good. I can’t help but ask: are these problems exclusive to the lowest levels of organizations, i.e. atomic teams, or are they more endemic?

There’s no reason to think that the disease isn’t wide-spread. After all, for a century we are perpetuating Taylor’s and Ford’s ideas of separating the workforce from workflow design. It doesn’t happen on the factory floor only but throughout the whole hierarchy. A higher rank designs how lower rank works and what is expected of them. It is, in fact, the hierarchy itself that discourages us to distribute autonomy more than absolutely necessary.

What we are looking at is not just a marginal problem of line employees going shallow into the higher ranks. The injury is not a scratch but a broken leg.

The Band-Aid

Despite how widespread the disease is the solution we have is far from enough: self-organization… but just at a team level. It is exactly the proverbial band-aid for a broken leg. It does the work, i.e. stop the bleeding, but only as long as the injury is skin-deep.

We know it’s not the case.

And yet we keep curing our broken organizational leg with just more band-aids of atomic teams embracing more autonomy. At the same time, we don’t address the structural problem of lack of autonomy throughout the hierarchy.

There lies the root cause of the problem. Working only on the lowest possible level, i.e. teams, we already have hard constraints of how far we can go with autonomy (and it’s not far really). Unless we start working on self-organization systematically, we won’t get much long-term effect in an organization. It would be just one more band-aid.

The Cure

We got principles missing when we were figuring out how to scale Agile up. Interestingly enough, it had long been figured out in the military. Even more curious, the problem had been solved with tangible practices and not with some vague aspirations. The difference is that the military practices were designed as scalable from the very beginning.

Take briefing and debriefing as an example. It is a pair of activities of sharing the goals and the context (the orders) by an officer to a unit and having the unit brief back to the officer what they understood. The goal of briefing and debriefing is for any rank to make sure that: a) a lower rank unit understands the goal (the purpose) of a higher rank officer and one rank above, and b) a lower rank unit understood correctly what was briefed.

Such a practice is rank-agnostic. It can be applied at any level of a hierarchy without any specific adjustments. It is entirely not so with Agile self-organization practices that were immersed in 7 plus or minus 2 people as a definition of a team.

If we aspire to see organizational transformations that would be an equivalent of turnaround of some of our teams, we need to reinvent self-organization. Autonomy distribution must become either a rank-agnostic practice or it has to have dedicated solutions for each organizational level.

The former, while much harder to design and implement, is potentially much more applicable. It is the domain where tools such as decision making process, open salaries, or inclusive hiring process reside. The meta pattern here is that by default any decision is made after collective advisory process and at a lower level that it would have been made otherwise.

I acknowledge that these examples may sound radical. They are, indeed. And yet adjusting them to a softer form is straightforward. It doesn’t have to be that anyone can decide about anyone else’s salary. It can be that anyone can decide about anyone else’s salary within their team and in accordance with budget constraints. What matters is that the decision is made at a lower level (a team mate and not a manager) and the whole team is invited to take part in the process.

Such a change won’t happen overnight. Even in a small organization it likely requires years and not months to implement. However, unless there is a motion toward that direction, we are just paying lip service to self-organization and apply more band aid to broken legs.

November 20, 2018
Why Collective Intelligence Beats Individual Intelligence

As long-term readers likely know I am a big fan of the idea of collective intelligence and big proponent of optimizing teams toward high collective intelligence.

First, what is collective intelligence? The easiest way of explaining that is through the comparison to individual intelligence (IQ). While IQ tests differ in type the pattern is similar: we ask an individual to solve a set of complex problems; the better they perform the higher their IQ is.

By the same token, we can measure intelligence of teams through measuring how well a group solves a series of complex problems.

There are a few very interesting findings in the original research on collective intelligence. It all starts with an observation that collective intelligence beats the crap out of individual intelligence. In highly collectively intelligent teams’ solutions provided by a group were systematically significantly better than solutions offered by any individual, including the smartest person in the room. However, even in teams with low collective intelligence the group solutions were on par with the best option provided by an individual.

It totally makes sense when we think of it. No matter how smart the solution provided by an individual is it most likely can be improved through clues and suggestions provided by others. Either directly or indirectly. And it doesn’t matter whether the others are even smarter. The thing that matters is that they think differently.

This theme is portrayed well in some pop-cultural productions. In Sherlock series the protagonist surprisingly frequently refers to his sidekick—John Watson—as not too clever or even dumb. On even more occasions Sherlock stresses that he needs Dr. Watson to inspire his superior mind. It’s not that Watson is smarter than Holmes. It’s that together they are smarter than Holmes alone, even given his prodigious mind.

The same pattern has been exploited in House M.D. series, where the team’s effort was consistently beating individual effort. It was so even if the final solution was facilitated mostly through the brilliance of the main character.

As a matter of fact, collective intelligence in play is one of those things that you can’t unsee once you’ve seen it. Like the other day, when I was sharing the idea of a workshop with one of my colleagues and I mentioned one feature I’d love to add to the app I was going to use during the workshop. The problem was that we explored an idea to add that feature before and, because of some old architectural decisions, adding the feature was no easy feat. Thus, we gave up. My colleague listened to my complaints and asked why we wouldn’t just add a simple and dirty hack just for the sake of the workshop. I was so immersed with the whole context of how hard it was to do it properly that the idea wouldn’t even cross my mind, no matter how obvious it might sound in retrospect.

And it wasn’t even a context of a persistent team; merely an ad-hoc discussion in a random group. Think, how much more we contribute in a more permanent setup—in a team which shares the same context on a daily basis.

The interesting follow-up to the observation that collective intelligence is supreme is that collective intelligence doesn’t depend on individual intelligence. As a matter of fact, there’s no correlation between the two. In other words, hiring all the smartasses doesn’t mean they’d constitute a team of high collective intelligence.

It is likely better to support a brilliant mind with folks who aren’t nearly as eloquent but provide another, diverse, point of view that to get more of the brilliance. What’s more a team built out of people of average intelligence can be better off than a bunch of smart folks gathered together.

It is because collective intelligence—the brilliance of a group—isn’t fueled by smarts but by collaboration. Two critical factors for high collective intelligence is social perceptiveness and evenness of communication. The former is awareness of others, empathy, and unselfish willingness to act for the good of others. The latter is creating a space for everyone to speak up and facilitating the discussions so that all are involved roughly equally. Neither of these attributes directly taps into individual intelligence.

That’s, by the way, where pop-cultural references fall short. Neither Holmes nor House care about the collaborative aspect of work of their teams and both make a virtue out their utter lack of empathy. It means that their teams are of low collective intelligence. I can’t help but thinking how much they could have achieved had they been optimized more toward collective intelligence.

Most of our industry fall in the very same trap when hiring. Tremendous part of our recruitment processes is optimized toward validating individual skills following a subconscious belief that this is what’s going to make teams successful.

As Dan Kahneman observes in his classic Thinking Fast and Slow, if our brain can’t easily answer to a difficult question it subconsciously substitutes the question with a similar one which is easy to and treats the answer to the latter as if it was the answer to the former. In this context we may be substituting a difficult question about how a candidate would perform in a team with much simpler one about how they would perform individually. The problem is that the assessment of a candidate may be very different depending on which question we answered.

If we truly want to optimize our teams for good collaboration we need to focus on the aspects that drive collective intelligence. We need to focus on character traits that are not that easy to observe, and yet they prove to be critical for teams’ long-term success, such as perceptiveness, awareness, empathy, compassion and respect. Ironically, such a team will outsmart one built around smarts and wits.

October 3, 2018
Emergent Purpose

There are those presentations at conferences that stay with us for a long time, even if there seems to be no particular reason for that. And yet they keep coming back for one reason or another. One of such presentations for me was a discussion between Arne Roock and Simon Marcus from Lean Kanban Central Europe years back.

Even though the topic of the discussion was broader there is one context that keeps coming back to me. Autonomy and alignment. A recurring theme was that we can’t enable autonomy unless we have alignment around a strategy, a goal, or whatever is the thing that orchestrates individual efforts.

As Peter Senge in his classic The Fifth Discipline puts it:

To empower people in an unaligned organization can be counterproductive.

It obviously makes sense. I mean, distributing autonomy is all fine but also creates a risk that everyone would pull an organization toward a different direction. Alignment, which goes through understanding of a common goal, helps up to focus on rowing in the same direction.

At the same time, watching the session back then, I couldn’t help but thinking that we at Lunar Logic hadn’t been doing that. We’d been continuously distributing more and more autonomy to everyone and at the same time there hadn’t been any official strategic purpose set for the organization for quite some time.

It the spirit of the discussion between Arne and Simon, who I both respect a lot, that should feel wrong. And yet it didn’t.

I could even remember my earlier discussions with Jabe Bloom. Jabe was pointing how important were techniques he adopted to help people connect their everyday behaviors with strategic goals.

Nonetheless, I still felt like imposing a strategy onto Lunar Logic would be a bad move.

It was months later when I came across the concept of emergent purpose. In its spirit it’s all about understanding organizational culture. It starts with an assumption that everyone at an organization has their individual purpose and it is only natural to pursue that individual purpose. It means that, given no other guidance, everyone would work toward achieving their own personal goals. Some people would have goals similar to others. Some would have very distinct aspirations. Some would have much stronger drive to achieve their own goals than other who would be fine going with the tide.

If we tried to visualize that as forces pulling an organization in different directions it might have looked like this.

As a matter of fact it would also mean that there is an aggregated force pulling the organization in some direction. And that aggregated force is exactly an emergent purpose.

By its design we don’t set an emergent purpose. It’s simply the outcome of individual purposes. It also means that for some people in an organization the emergent purpose may be the exact opposite of what they individually want. That’s all fine.

Despite the fact that it’s an emergent property of any organization, we have means to influence the emergent purpose. It happens through hiring. When someone leaves an organization their influence on emergent purpose disappears. At the same the organization hires someone new whose expectations may be better aligned with the emergent purpose.

Through such a change the emergent purpose has been amplified.

There is interesting dynamics in that process. If my own goals are aligned with the purpose of the organization I’m with, it is less likely that I’d leave the organization than if it was otherwise. And corollary to that, my chance of being hired and wanting to join an organization is higher if there is alignment in place.

In other words emergent purpose tends to sustain and even amplify itself, even with no conscious effort from leaders of an organization.

The final, and most important bit about the idea of emergent purpose is that every organization has an emergent purpose. It doesn’t matter whether they have an official strategic purpose or not, or how strong it is, or whether there is alignment between a strategy and an emergent purpose. It’s always there, as the only way to get rid of it would be to make people stop having any ambitions, which is an equivalent of not having any people in an organization, I guess.

That’s exactly where the fun starts. Given that there always is an emergent purpose, we’d be dumb not to listen to it. Now, I don’t say we necessarily need to pursue it actively, yet understanding it is crucial.

The reason is that whatever strategy we choose there will likely be a gap between that strategy and the emergent purpose. The bigger the gap the more people would get disengaged and likely eventually leave. From that perspective there is a price to pay for any strategy and, simply put, the better we understand the emergent purpose the better we are suited to achieve our strategic goal. Also, in simple economic terms, there may be strategies that simply are too costly to pursue.

Ideally, you can do what we did at Lunar Logic. We basically turned our emergent purpose to a company strategy. Instead of imposing a strategy on everyone we listened to each other and figured what’s the most desired path we want to pursue for the time being. That’s how we evolved our aspiration from helping to build products for our customers efficiently to helping the customers to succeed with their products. The latter isn’t focused on the building part nearly as much as the former.

Interestingly enough, out of the potential strategies that we discussed there was one which would make me leave the company eventually. Luckily for me it didn’t end up being our emergent purpose after all.

Of course I understand that few companies would go as far as we did. Even though I think it is an awesome idea I don’t encourage organizations to make that bold move. Nevertheless, knowing what the gap between aspirations of leaders of a company and everyone else is crucial if we look for any reasonable level of sustainability.

Finally, emergent purpose is also one of possible answers for autonomy and alignment issue. As long as we understand what an emergent purpose is we can decide to stick with it or just slightly shape it instead of building alignment externally through officially set strategic goals.

June 1, 2018
Empathy and Respect: What Makes Teams Great

I’ve been known to bring up research on collective intelligence in many situations, e.g. here, here, or here. In my personal case, the research findings heavily influenced my perception of how to build teams and design organizations. The crucial lesson was that social perceptiveness and having everyone being heard in discussions were key to achieve high collective intelligence. This, in turn, translates to high effectiveness of a team in pretty much any flavor of knowledge work.

Since the original work was published, the research has been repeated and findings were confirmed. Nevertheless, in software industry we tend to think we are special (even though we are not) and thus I often hear an argument that trading technical skills for social perceptiveness is not worth it. The reasoning is that technical skills easily translate to better effectiveness in what is our bread and butter—building software. At the same time fuzzy things, like e.g. empathy, do not.

The research, indeed, was run on people from all walks of life. At the same time every niche has some specific prerequisites that enable any productivity. I don’t deny that there is specific set of technical skills that is required to get someone contributing to work a team tires to accomplish. That’s likely true in an industry and software development is no different.

As a matter of fact, enough fluency with engineering is something we validate first when we hire at Lunar Logic. The way we define it, though, is “good enough”. We want to make sure that a new team member won’t hamper a team they join. Beyond that, we don’t care too much. It resonates with a simple realization that it is much easier to learn how to code than it is to develop empathy or social perceptiveness in general.

The whole approach is based on an assumption that findings on collective intelligence hold true in our context. Now, do they?

Google is known to be on their quest to find what’s the perfect team for years. Some time ago they shared what they learned in a few year-long research that involved 180 Google teams. It seems they confirmed pretty much everything that has been in the original Anita Woolley’s team work.

It’s not the technical excellence that lands teams in the group of accomplishers. By the way, neither is management style—it was orthogonal to how well teams were doing. The patterns that were vividly seen were caring about other team members and equal access to discussion time.

What’s more, the teams which did well against one goal seemed to do well against other goals as well. Conversely, teams that were below average seemed to be so in a consistent manner. The secret sauce seemed to work fairly universally against different challenges.

What a surprise! After all, we are not as special as we tend to think we are.

I could leave it here, as one of those “You see? I was right all that time!” kind of posts. There is more to learn from the Google story, though. Aspects that are mentioned often in the research are norms, either explicit or implicit. This refers to specific behaviors that are allowed and supported and, as a result, to organizational culture.

When we are talking about teams, we talk about culture pockets as teams, especially in a big organization, may differ quite a bit one from another.

It seems that even slight changes, such as attitude in group discussions, can boost collective effectiveness significantly. If we look deeper at what drives such behaviors we’ll find two keywords.

Empathy and respect.

Empathy is the enabler of social perceptiveness. It is this magic powder that makes people see and care for others. It pays off because empathic person would likely make everyone around better. Note: I’m using a very broad definition of empathy here, as there is a whole discussion how empathy is defined and decomposed.

Then, we have respect that results in psychological safety, as people are neither embarrassed nor rejected for sharing their thoughts. This, in turn, means that everyone has equal access to ongoing conversations and they are heard. Simply put, everyone contributes. Interestingly enough, it is often perceived as a nice-to-have trait in organizations but rarely as the core capability, which every team needs to demonstrate.

Corollary to that is an observation that both respect and care for others are deep down in the iceberg model of organizational culture. It means that we can roughly sense what are capabilities of an organization when it comes to collective intelligence. It’s enough to look at the execs and most senior managers. How much are they caring for others? How respectful are they? Since the organizational culture spreads very much in a top-down manner it is a good organizational climate metric.

I would risk a bold hypothesis that, statistically speaking, successful organizations have leaders who act in respectful and empathic way. I have no proof to support the claim, and of course there’s anecdotal evidence how disrespectful Steve Jobs or Bill Gates were. That’s why I add “statistically speaking” to this hypothesis. Does anyone have a relevant research on that?

Finally, there is something that I reluctantly admit since I’m not a believer in “fake it till you make it approach”. It seems that some rules and rituals can actually drive collective intelligence up. There are techniques to take turns in discussions. On one hand it creates equal access to conversation time. On the other if fakes respect in this context. It challenges ego-driven extroverts and, eventually, may trigger emergence of true respect.

Similarly, we can learn to focus on perception of others so that we see better how they may feel. It fakes empathy but, yet again, it may trigger the right reactions and, eventually, help to develop the actual trait.

In other words we are not doomed to fail even if so far we paid attention to technical skills only and we ended up with an environment that is far too nerdy.

However, we’d be so much better off if we built our teams bearing in mind that empathy and respect for others are the most important traits for candidates. Yes, for software developers too.

September 5, 2016
Hierarchy Is Bad For Motivation

Whenever a topic of motivation at work pops up I always bring up Dan Pink’s point. In the context of knowledge work, in order to create an environment where people are motivated we need autonomy, mastery, and purpose.

The story is nice and compelling. However, what we don’t realize instantly is how high Dan Pink sets the bar. Let me leave the purpose part aside for now. It is worth the post on its own. Let’s focus on autonomy and mastery.

First of all, especially in the context of software development, there’s a strong correlation between the two. Given that I have enough autonomy in how I organize my work and how the work gets done, I most likely can pursue mastery as well. There are edge cases of course, but most frequently autonomy translates to mastery (not necessarily so the other way around though).

The problem is that the way organizations are managed does not support autonomy across the board. Vast majority of organization employs hierarchy-driven structures. A line worker has a manager, that manager has their own manager, and so on and so forth up to a CEO.

The hierarchy itself isn’t that much of an issue though. What is an issue is how power is distributed within the hierarchy. Typically specific powers are assigned to specific levels of management. A line manager can do that much. A middle manager that much. A senior manager even more. Each manager is a ruler of their own kingdom.

Why is power distribution so important? Well, ultimately in knowledge organizations power is used for one purpose: making decisions. And decision-making is a perfect proxy if we are interested in assessing autonomy.

Of course each ruler has a fair level of flexibility when it comes to decide how the decision-making happens in their teams. There are, however, mechanisms that discourage them to change the common pattern, i.e. a dictatorship model.

The hierarchical, a.k.a. dictatorship, model has its advantages. Namely it addresses the risks of indecisiveness and accountability. Given that power is clearly distributed across the hierarchy we always know who is supposed to make a decision and thus who should be kept accountable for it.

That’s great. Unfortunately, at the same time it discourages attempts to distribute decision-making. As a manager I’m still kept accountable for all the relevant decisions made so I better make them myself or double-check whether I agree with those made by a team.

This in turn means that normally there’s very little autonomy in hierarchical organizations.

It brings us to a sad realization. The most common organizational structures actively discourage autonomy and authority distribution.

If we come back to where we started – what are the drivers for motivation – we would derive that we should see really low levels of motivation out there. I mean, vast majority of companies adopt the hierarchical model as it was the only thing there is. Not only that though. Even within hierarchical model we may introduce a culture that encourages autonomy, yet very, very few companies are doing so.

We could conclude that if the above argument is true we would expect really low levels of motivation globally in the workforce. It is a safe assumption that high motivation would result in engagement and vice versa.

Interestingly enough Gallup run a global survey on employee engagement. The bottom line is that only 13% of employees are engaged in work. Thirteen. It would have been a shock if not the fact that we just proposed that one of the current management paradigms – a prevalent organizational structure – is unsuitable to introduce autonomy across the board and thus high levels of motivation.

In fact, active disengagement, which would translate to being openly disgruntled, is universally more common that engagement. Now, that tells a story, doesn’t it?

What we look at here is that modern workplace is not well-suited for achieving high motivation and high engagement of employees. There are certain things that can change the situation within structural constraints. There are good stories on how to encourage the right behaviors without tearing down the whole hierarchy.

It is also a challenge for a dominant management paradigm that makes a rigid hierarchy a prevalent and by far the most popular organizational structure out there. While such hierarchy addresses specific risks it isn’t the only way of dealing with them. The price we pay for following that path is extremely high.

I for once consider that price too high.

June 22, 2015
Why We Want Women in Teams

One of the messages that I frequently share is that we need more women in our teams. By now I’ve faced the whole spectrum of reactions to this message, from calling me a feminist to furious attacks pointing how I discriminate women. If nothing else people are opinionated on that topic and there’s a lot of shallow, and unfair, buzz when it comes to role of women in IT.

Personally, I am guilty too. I’ve been caught off guard a few times when I simply shared the short message – “we need more women in our teams” – and didn’t properly explained the long story behind.

Collective Intelligence

The first part of the story is the one about collective intelligence. We can define the core of our jobs as solving complex problems and accomplishing complex tasks. We do that by writing code, testing it, designing it, deploying it, but the outcome is that we solved a problem for our customer. In fact, I frequently say that often the best solution doesn’t mean building something or writing code.

If we agree on problem solving frame a perfect proxy for how well we’re dealing with it is collective intelligence. Well, at least as long as we are talking about collaborative work.

Anita Woolley’s research pointed factors responsible for high collective intelligence: high empathy, evenness of communication in a group and diversity of cognitive styles. These are not things that we, as the industry, pay attention to during hiring. Another conclusion of the research is that women are typically stronger in these aspects and thus the more women in a team the higher collective intelligence.

Role of Collaboration

There are two follow up threads to that. One is that the research focused only on one aspect of work, which can be translated to collaboration. That’s not all that counts. We can have a team that collaborates perfectly yet doesn’t have the basic skills to accomplish a goal. Of course all the relevant factors should be balanced.

This is why at Lunar Logic, during hiring process, we verify technical competences first. This way we know that a candidate won’t be a burden for a team when they join. Once we know that somebody’s technical skills are above the bar, we focus on the more important aspects, but the first filter is: “can you do the job?”

The decision making factors are those related to the company culture and to collaboration.

Correlation and Causation

Another thread is that “more women” message is a follow up to an observation that women tend to do much better in terms of collective intelligence. I occasionally get flak for mentioning that women are more empathetic. It would typically be a story about a very empathetic man or a woman who was a real bitch and ruined the whole collaboration in a team.

My answer to that is I don’t want to hire women. I want to hire people who excel at collaboration. If I ended up choosing between empathetic man and a cold-blooded female killer it would be a no-brainer to me. I’d go with the former.

What is important though is that statistically speaking women are better if we take into consideration aforementioned aspects. It’s not like: every woman would be better than any man. It’s like: if we’ve been hiring for these traits we’d be hiring more women than men.

And that’s where a discussion often gets dense. People would imply that I say that women are genetically better in, say, collaboration. Or pretty much the opposite, they’d say that in our societies we raise women in a way that their role boils down to “good collaborators” and not “achievers.”

My answer to that is: correlation doesn’t mean causation. I never said that being a women is a cause of being empathetic and generally functioning better in a group. What I say is that there is simply correlation between the two.

The first Kanban principle says “start with what you have” and I do start with what I have. I’m not an expert in genetics and I just accept the situation we have right now and start from there.

The Best Candidate

A valid challenge for “hire more women” argument is that it may end up with positive discrimination. My point in the whole discussion is not really hire women over men. In fact, the ultimate guidance for hiring remains the same: hire the best candidate you can.

It just so happens that, once you start thinking about different contexts, the definition of “the best candidate” evolves. A set of traits and virtues of a perfect candidate would be different than what we are used to.

And suddenly we will be hiring more women. Not because they are women. Simply, because they are the best available candidates.

Such a change is not going to happen overnight. Even now at Lunar I think we are still too much biased toward technical skills. And yet our awareness and sensitivity toward what constitutes a perfect candidate is very different than it was a few years ago. That’s probably why we end up hiring fairly high percentage of women, and yet we’re not slaves to “hire women” attitude.

Finally, I’d like to thank Janice Linden-Reed for inspiration to write this post. Our chats and her challenges to my messages are exactly the kind of conversations we need to be having in this context. And Janice, being a CEO herself and working extensively with IT industry, is the perfect person to speak up on this topic.

May 12, 2015
Culture Pockets

Organizational culture is one of these areas that I pay a lot of attention to. Over years I started valuing the role of the culture increasingly more and more. The biggest difficulty though is that organizational culture is a challenging beast to control.

Organizational Culture

organizational culture
the behavior of humans who are part of an organization and the meanings that the people react to their actions
includes the organization values, visions, norms, working language, systems, symbols, beliefs, and habits

If we look at how organizational culture is defined there are two things that are crucial. One thing is that is a culture is formed of behaviors of all people in an organization. The other is that it’s not only about behaviors but also about what drives these behaviors.

When we look at it we realize that there’s no easy way to mandate a culture change. We can’t simply say: from now on we are a learning organization or that we will value collaboration starting on June the 1st.

If we want to see a change of a culture we need to see change in behaviors. Bad news though is that change of behaviors can’t really be mandated either. I mean we can install a policeman who will make sure that everyone behaves according to the new policy we issued. What would happen when a policeman is gone? We can safely assume that over time more and more people would retreat back to the old status quo – behaviors they knew and were comfortable with. The change would be temporary and ephemeral.

Identifying Culture

If we want to approach a cultural change we first need to understand the existing culture. What is valued? What principles the organization lives by? How is it reflected in everyday behaviors? Without understanding the starting point changes would be rather random and doomed to fail.

How to identify the culture then? Look at behaviors. Ultimately the culture is a sum of behaviors of people who are a part of the organization.

There is a serious challenge that we’re facing on that front. Not everyone has equal influence over organizational culture. In fact, the higher in the hierarchy someone is the more influence they typically have.

The mechanism is simple. Higher up in the hierarchy I have more positional power and my decisions affect more people. One specific type of decision I make, or at least strongly influence, is who gets promoted in my team. Given all my biases, I will likely promote people who are similar to me, share similar values, and behave in similar way. I perpetuate and strengthen the existing culture.

That’s by the way the rationale behind an advice I frequently share: if you want to figure out what the organizational culture of a company is look at its CEO. The CEO typically has the most positional power and thus their influence over the company is the biggest one. The way they behave will be copied and mimicked across the board.

Of course we need to pay attention to everyday behaviors and not to what is the official claim of the CEO. Very frequently there would be a gap between the two. That’s something I call authenticity gap. An organization claims one thing but everyday behaviors show another. For example they claim to care about customer satisfaction and then they bullshit their customers when it comes to share the project status.

This alone says something about culture too (and not a good thing if you need to ask).

Culture Change

How do we influence the cultural change then? If we can influence the factors that drive behaviors, and thus the culture, resulting changes would influence the culture. It’s even better. When we’re changing organizational constraints we potentially influence change of behaviors across the board and not only in an individual case.

We already established though that not everyone has equal influence on the culture. People at the top, in the long run, will have an upper hand. First, they control who gets promoted and as a consequence who has positional power. Second, that power is needed to change organizational constraints: introduce new rules, change the existing ones, and establish what acceptable and what’s not.

A simple answer how to change organizational culture would be to get top management on board, and help them understand what it takes to influence the culture.

Unfortunately, few have comfort of doing that.

Does it mean that we are doomed? Does it mean that without enlisting top ranks any attempt to change organizational culture will fail? Not necessarily so.

Culture Pockets

I believe I learned about the concept of culture pockets from Dave Snowden in one of his presentations. The basic idea is that within a bigger, overarching culture we can develop and sustain a different culture.

Another label that is used to describe this concept is a culture bubble.

When we think about this frame, from the top of our heads we can come up with some examples. One would be multinational organizations that have offices all around the world. Because of geography and cultural differences each of the local offices will have at least slightly different organizational culture. You would expect to see a different vibe in an office in India, in Poland, and in USA, even if they are the parts of the same company. Even if that company has pretty uniform culture.

There are examples of introducing culture pockets or culture bubbles when everyone works in the same building too.

One such idea is Lean Startup. One obvious context of applying Lean Startup ideas are startups. Another, and quite a common one, is when big organizations decide to build their product according to Lean Startup principles.

Such a team would operate very differently and very independently from the rest of the organization. Constraints would be different and so would be everyday behaviors. We’d have a culture pocket.

Another similar example is Skunkworks. It’s an idea developed by Lockheed Martin and it boils down to a similar pattern. Lockheed Martin would occasionally run a project in Skunkworks – a very independent team that has a lot of freedom and autonomy. Clearly without all the typical constraints enforced by the company their culture is different than one seen in majority of the company. By the way, a project in this case means designing and building a whole new fighter aircraft or something of similar complexity.

If we go by that analogy, every team can be a culture bubble. It is enough that the constraints within which that team operates are different from those that are standard for the whole organization. This type of culture pocket can go only as far as the team has positional power to redesign their constraints of course. The more positional power there is the bigger the difference of what is happening within and outside of a culture bubble.

Creating a Culture Bubble

Creating and maintaining a culture pocket is a balancing act. One thing is kicking off the change. That would typically mean someone defining different rules for a part of an organization. It can simply be a team of a few people.

Normally any positional power would be an attribute of a manager. This means that such a change needs to involve that manager. They need to change rules, norms, and expected behaviors. Alternatively they need to let others decide about such stuff, i.e. give up on the power they’ve been assigned.

There is another role for mangers in a setup too. They main responsibility is to sustain the culture bubble. When a culture pocket is established there’s effort needed to keep it going within broader, sometimes even unfriendly, culture of the whole organization.

To give you an example, from a perspective of the whole organization it doesn’t matter at all how decisions are made in a team. What matters that there is no problem with indecisiveness and accountability. The way most organizations understand these concepts would mean that a manger has to be decisive and can be kept accountable. It may still be true even if decisions are made by the whole team using e.g. a decision making process.

Fragility of Culture Pockets

The biggest risk related to culture pockets is that they are fragile. Typically they base on the fact that some people, who were in power, distributed that power for a better good. It doesn’t mean, however, that when they are replaced with someone else a new person will keep a similar attitude.

A safe thing in such a situation is to adjust to whatever is the overarching culture of the whole organization. It means that a culture bubble is gone as there’s no longer anyone who take cares of translating the two cultures back and forth.

The message I have is twofold. On one hand if we want to see a fundamental and sustainable cultural change we need to get top ranks involved eventually. Without that we won’t address the risk of fragility of culture pockets. On the other hand, a simple fact that in a big organization we can’t simply change the culture of the whole company doesn’t mean that we have no options whatsoever.

From my experience culture pockets, even if fragile and to some point ephemeral, are a perfect vehicle for self-realization of people inside. For people in leadership and management positions they are sometimes the only way to maintain internal integrity.

Finally, sometimes it is the only option if we want to influence the cultural change.

April 30, 2015