We can consider so many things both in our professional and personal lives as value exchange. The most obvious case: I exchange 40 hours of my time each week for a set amount of money that lands in my bank account each month.

As a business, we do the same thing. We commit our engineers to spend their time on whatever our clients need them for, and in exchange, we receive an agreed-upon rate for each hour of that effort.

In fact, I often use that frame when describing how we perceive our contributions. We aspire our clients to be happy with the value we deliver for the price they pay for the whole team.

What Is Value?

Now, the tricky part in these examples is value. While we can easily assess how many hours anyone spends on a task, the time doesn’t automatically translate to value. What’s more, it’s not even purely a matter of how one will spend that hour.

I can work on an activity that has only certain odds of success. If the outcome ultimately emerges as a failure, no value will have been delivered. The reasons for that may be entirely outside my sphere of control.

As an example, think of all the effort I invest into helping a potential client improve how they will approach building their new product just to see them choose a different partner. In this case, my work has not yielded any value for Lunar.

However, even if I work on something that we assume to have intrinsic value, it’s still tricky. Let’s look at adding a feature to a product. (And yes, I know that not every feature is value-adding. In fact, there are some whose net value would be negative.)

Assuming the feature I’m building will have a positive effect, the big question is how big of an impact and how much our client values it. That question is almost universally highly challenging.

Most of the time, we can’t know the answer upfront. We need to build the thing to be able to validate the outcome. Most of the time, however, we don’t try to check that anyway. Even if we did, most of the time, the early validation will now give the complete picture.

Think of The Shawshank Redemption. Its theatrical release was largely a flop. And yet, over the years, it gathered a strong fanbase, still keeps the #1 position as the best movie ever at IMDB, and eventually, it at least paid off production costs. Not a bad outcome for a flop, eh?

While there obviously is a correlation between the opening weekend box office and the eventual financial success of a movie, we can’t precisely know the financial success/failure just after the first few days.

The same goes for value assessment in most of the knowledge work. You could just as easily consider whether paying an employee any specific salary yields a valuable (enough) outcome. And the smaller chunk of work you look at, the more the mileage will vary.

Making Value Exchange Work

We use two basic coping mechanisms to work around uncertainty about value.

The first one is ignoring the actual value altogether and sticking with our early assumptions of what we expected it to be. It’s like deciding to build that feature because “it will bring us so many new subscribers” and never looking back. Sure, before committing to the development, we might have asked for an estimate. If it was acceptable enough (and the work didn’t take much longer), it was the last time we did any assessment of the work.

We thought it would bring us a ton of subscribers, and it was a sound decision to pay $10k for that. Oh, and since we already paid for that work, who cares whether it actually brought a single new soul to our solution?

Well, I’d say this means giving up on a ton of learning here, and that’s of huge value by itself, but I clearly must be wrong, as very few product organizations do any post-release validation.

The second way to dodge the uncertainty of value is by looking at a bigger whole. I don’t try to assess whether an engineer has been productive during every single hour or day. Heck, I’d be perfectly fine with a slower week, too. However, I want to know whether their long-term performance justifies their salary.

By the same token, I want the whole team working for a client to deliver good value for money in the long run. So, if we look at the weeks or months of work of the whole group, we are happy with the value of everything they deliver (of course, in the context of what that effort costs, again, in total).

In extreme cases, you could look at movie studios or VCs investing in startups. They are happy to weather plenty of bad investments as long as that one movie or that one startup yields a 100x or more return.

Lateral Skillsets

We all make one subconscious assumption here. That is, even though we exchange different things, they are of similar value for both parties. If we ask for $90 an hour for our developers, that hour would be priced roughly a similar way, whether by Lunar’s client or me. Or rather, we would price the skills our client rents for that hour similarly.

This assumption, though, often doesn’t hold true.

To stick with the engineering/software development context. When our potential clients want to assess our team’s skill set, it will almost always be heavily skewed toward technical skills. After all, when you hire developers, they will do development, right?

But let me redefine the situation here. Imagine you seek someone to turn your idea into an MVP. You have two candidates with very similar technical skills. However, one builds their experience by working on many different small engagements, including several very early-stage products. The other spent big chunks of their time working on very few large and complex solutions.

Which one would you choose?

I bet most of us would go with the former over the latter, as we’d deem their experience more relevant. This relevancy, however, stems from a lateral skillset. It’s not an ultimate value. It’s value in the context.

Product management skills may actually emerge as the most crucial for that role, even if we don’t consider it so upfront. At the early stage of product development, building the wrong thing is rarely salvageable. Building the thing wrongly, on the other hand, can typically be saved.

If we had considered a different gig, we might have chosen differently.

This is but one example of lateral skills that may make or break any endeavor. A broad range of people skills, project management savvy, business context understanding, and more may be similar game-changers here.

And yet, without the specific context, the broad market would largely ignore those traits. Even within the context, they are most often omitted.

Asymmetric Value Exchange

The lateral skills are what change the economy of the whole value exchange. The job market would value two similarly technically skilled developers, well, similarly. After all, across a wide variety of challenges, they will provide comparable value.

However, within the early stage product development context, the first one will deliver something extra. They wouldn’t be working extra hours, their code wouldn’t objectively be better quality, they wouldn’t be faster.

Yet something that costs nothing extra to that developer–their lateral early product management skills–would be highly beneficial for the product company.

That’s what breaks the simple economy of value exchange. I add to the mix something that’s of little to no cost for me but gives the other party a big upside.

In other words, I give up nothing while they gain a lot.

Suddenly, the whole deal has so much more wiggle room, which can be used to make it more attractive for both parties.

Not only that, though. It also generates additional options for value delivery. Our developer may use their time building a feature that ultimately will not help. However, thanks to their experience, they can also suggest (in)validating the whole part of an app prior to committing to development. That, in turn, may lead to much more significant savings.

In this case, exploiting lateral skills makes the value exchange asymmetric. Why is it important? It’s because whenever you can find a partnership with an asymmetric value exchange, it’s a plain win-win scenario for both parties.

Since lateral skills typically create these scenarios, we should pay much attention to them.

Side Skills Are Core Skills

If I looked for a technical partner to help me with an early-stage product, I would primarily be looking for stories about discovery work, building MVPs, validation, etc.

As a matter of fact, I’d be explicitly asking for failure stories. I mean, we know the data. New products do fail. So, if the only thing someone has to show is a neat streak of successes, you can be sure they’re in a fantastic realm.

One of my mantras is, “Many of our past clients paid us to fail, so you don’t have to. You get all the experience we got from that as a part of the package.”

These lessons do not fall into what’s commonly perceived as “core skills” for software development teams. And yet, we do consider them core. We shine most when we’re able to utilize those side skills.

So, go figure out what constitutes those lateral skillsets in your context. These are the core traits you should be looking for, whether hiring or choosing a partner in your endeavors.

I admit I designed or helped to design 5 assessment systems in my career. No, I’m not proud. Frankly, I’m pretty sure the first 3 brought net negative value, i.e., they created more harm than value.

So when we set out to reinvent our salary system, I said publicly (and more than once): “An assessment system? Over my dead body.”

Fast forward 7 years, and it was time to eat my own words. While the change to transparent salaries was a big thing, and literally no one would instead go back to what we had before, we saw issues piling up.

An interesting fact, among others, some of the issues were:

• Raises not happening frequently enough
• Too little money spent on salary increases

And yes, that was all in a system where anyone could self-set their own salary.

Long story short, a part of the best way out we could devise meant introducing an assessment system.

The Fallacy of Assessment

Assessment systems are a standard in organizations, big and small. There are broadly accepted good practices, like including perspectives from everyone around (so-called 360 assessments) or focusing on facts (outcomes, observable behaviors, etc.).

The bottom line is the aspiration to improve the objectivity of any given assessment.

And that’s fool’s gold.

The fallacy of assessment systems in a professional context is that there’s no such thing as objectivity. There can’t be.

As Marcus Buckingham and Ashley Goodall eloquently explain in Nine Lies About Work, we’re fundamentally incapable of answering questions like “How good are Pawel’s software development skills?” or “How good of a leader is Pawel?”

That holds true even if we pretend to assess observable artifacts, like Pawel’s code or his behaviors during staff meetings. We could observe but a fraction of what a person employs to deliver the outcomes.

To make things worse, even when we consciously focus on observing Pawel’s visible behaviors and outcomes of his work, we will only see a tiny part of it. After all, we have our work, too, let alone all the other people in the team that we need to take care of as well.

Curiously enough, the closest person to objectively assess anything about Pawel will be himself. He knows most about his trials and tribulations as well as triumphs. He knows when he thrives and when he struggles.

Except we intuitively dismiss his assessment as subjective.

Thinking: Fast and Slow

One of the fundamental observations Dan Kahneman made in his Thinking: Fast and Slow was that whenever our brain faces a difficult question, it subconsciously changes it to a similar albeit simple-to-answer one.

Another one is that we typically make snap decisions and only then look for arguments supporting our choice (also actively dismissing those that would go against it).

Couple these two with our assessment example and the challenge described above. The question about Pawel’s development skills is difficult. The most honest answer I can give is that I don’t really know, and the best I could do would be to spend a lot of time trying to inform myself better, but a) I don’t want to do this, and b) it would only improve my answer by a thin margin.

But here’s a simple question that I can answer instantaneously. What is my opinion about Pawel’s development skills? Yes, the change may look subtle, but it makes all the difference.

The new question doesn’t force me to consider facts, outcomes, and observable behaviors alike. It literally goes for my judgmental opinion, which, of course, may take data into account. It may also include all the prejudice, bias, hearsay, and other sources of misinformation.

Obviously, it is explicitly subjective.

Yet, our lazy brain answers the simple subjective question while pretending it deals with a difficult and more objective one. Oh, and once it has the answer, it follows up by justifying it with all the supporting arguments it can find.

All the efforts to make the assessment system “more objective” are then thwarted by our brains.

No wonder so many people consider their assessment systems unfair.

The Way Out

Following Buckingham and Goodall’s advice, one might ask what would happen if we ditched the pretense of objectivity and embraced subjectivity. While I can’t give a general answer, here’s a story of what happened at Lunar.

The starting point was that we had a 360 assessment in place. We designed it around observable behaviors. The measured satisfaction with the assessment (and, broader, the salary system) was a whopping 80%.

If it ain’t broken, don’t fix it, they say. So that’s precisely what we did. We redefined our categories of flexibility, experience, effectiveness, and people skills with straightforward and subjective questions, such as:

• I would always want [that person] to be my leader.
• When a team requires multiple organizational and technical skills, I would always want [that person] to be on the team.
• Whenever there’s a role no one is willing to take, I would always count on [that person] to take the responsibility.
• etc.

We answer them on a scale from “I strongly disagree” to “I strongly agree.” Also, the “always” qualifier is important as it stretches the answers across the scale.

Initially, there were about a dozen of such questions. We wanted to ensure that all the aspects of the existing solution are covered.

After another iteration of the “old” assessments, I suggested we experimentally try the new approach and compare the results. It should have been an easy sell.

That’s when all hell broke loose.

I didn’t appreciate how much resistance there would be against trying something new, even when it wasn’t supposed to affect anything. Not unless we would have validated the outcomes, at least.

The new approach was considered explicitly subjective (as opposed to the perceived objectivity of the old one). It was expected its outcomes would affect the fairness of the payroll. People feared we would lose a lot of sophistication and details in assessments as the new questions were necessarily broad and generic. For example, we stopped mentioning any specific technologies we work with. Then, there was concern that people would start playing their favorites (I like you, so sure, I would love you to be my leader).

The Experiment

No amount of discussion could get everyone on board, but at least I could play the “let’s try it” card. If we didn’t like the outcome, nothing would change, after all.

What have we learned?

It was easier to answer the questions. We got significantly more answers in the new scheme (up from 47% to 65% of all possible responses).

It also took much less time to answer the subjective questions than when we pretended to be objective (about a half time spent on the activity, despite providing more responses).

The best thing?

The results correlated almost perfectly with the old system. The correlation coefficient was 0.98. That’s math for “these series are as identical as it gets.”

We literally generated the same results (or, in terms of quantity, better) with half the effort.

Many still felt uncomfortable with a blatant admission that we use individual opinions as assessments. Nonetheless, the experiment’s outcome spoke for itself.

We have been doing it all along; we’ve just cultivated an illusion of objectivity.

Summary

Two years down the timeline, no one looks back. We reduced the set of questions to just five. And if I wanted to get super-radical, we could stick with just one: “I would always want [the person] to be my leader.” This single response correlates most with all the categories we used to assess.

When you consider it, it makes perfect sense. There are many interdisciplinary traits and skills we’d expect from an ideal leader. We’d want them to support us as a person and professional. We’d turn to them with problems, both technical and interpersonal. We’d look for guidance and challenge in them. We’d want them to make the team better. Be fair to everyone. And many more.

If someone does well on all those accounts (and more), it is only fair to expect them to shine in a traditional skill/trait-based assessment, too.

Still, we want to stress some other aspects of our work explicitly as well. But that still leaves us with only five questions, which, in most cases, we can easily answer from the top of our heads.

I won’t say that we somehow started loving assessments. No one does that. But we:

• get the same quality
• but better quantity
• by spending much less time on the activity
• and are similarly satisfied with the system

What’s not to love?

An internet discussion (yeah, I know, quite a bad idea for a trigger) inspired me to share some of the uncommon things we do at Lunar when it comes to decision-making.

In short, as Lunar, anyone can make any decision as long as they go through an advisory process. The latter means consulting with people with expertise on the topic and those affected by a decision.

Very few edge cases (like letting people go) have a somewhat different process, but the vast majority of calls follow the pattern described above.

So how come people don’t get extravagant and give themselves hefty raises, go for super-fancy events, buy tons of gadgets, etc.?

Care

There are a few prerequisites to distributing autonomy that I could spend hours talking about. In fact, I’m doing exactly that during my course (called Progressive Organizations) at a local university. Anyway, for this consideration, the key prerequisite is care.

When I say care is needed when we give people the power to make (any) decisions, it means that they need to feel responsible for the outcomes of their calls. Whatever happens, good or bad, they won’t be like, “Meh. Whatever.”

They will care.

That is enough to avoid an obvious extravaganza. After all, if we can predict something might be, well, not very wise or cause controversy, we’d think twice before putting our reputation at stake.

Hard decisions

It’s easy to make an obvious call. Let’s organize a company offsite! We’ve been doing it to great success for a decade, so it’s kinda no-brainer, isn’t it?

But when it comes to tough choices, believe me, people don’t queue up to pick up the responsibility. It’s where it falls to the usual suspects: people who you’d consider leaders.

And sensibly so. After all, these are people who are equipped with experience, knowledge, and intuition for such situations. They’ve been doing it for years. That’s one of the reasons we keep them around.

Also, when in doubt about whether going for this fancy conference abroad is extravagant or not, the leaders would use past experiences and provide some context.

“Why wouldn’t you consider a more local event instead? Here’s one we’ve sent people to, and they’ve been happy.”

“Have you considered how everyone might treat these trips if we treat such an escapade norm?”

And suddenly, no one really wants to push for that.

Learning the culture

I love one challenge I often get when I talk about radical autonomy. “What stops people from giving themselves a hefty raise?”

That’s the best part. Nothing. And they still don’t do it.

When you join a new group–any new group–two things happen. First, you influence the group. You provide a new behavior, perspective, thoughts, needs, etc. However, the bigger the group, the smaller your influence. After all, you’re but one person.

More importantly, though, the group influences you, too. Whatever is the norm in how they behave, what they do, what is accepted and what is not, strongly influences how you act. That’s obvious. We want to belong.

The very same thing works when anyone joins an organization. No one on their first day (or week or month) attempts to reinvent how things are done here. We wait and orient ourselves. We observe and learn norms.

With decision-making, it means considering how, when, and what kind of decisions they make. What triggers controversy, and what goes as expected.

So, if a healthy norm is that we try to keep our payroll fair, no one in a blatant way violates the norm. It would be too high of a price to pay in social credit.

Not making decisions

OK, but that whole thing means that we departed from the idea that every decision has a designated decision-maker. My team leader accepts my time off requests, my director gives me a raise, and a VP greenlights strategic efforts. We’re no longer there. It’s like anyone who wants to act acts.

And if no one wants to act… Then what?

Ultimately, there are the most mundane or unpleasant decisions that no one would fancy. Show a person who actually likes to let people go because of economic reasons, and I’ll show you a psychopath.

Normally, we’d have a designated person who is responsible for those tough calls, but hey, we gave up on that idea.

We do, however, have a person who serves as a safety net. In Lunar case, it’s me. I’d do anything that no one else is willing to do (and yes, that’s why I throw rotten food from a fridge in our cantina). Part of that burden is making the toughest decisions.

Think of it not as a designated decision-maker but rather as a fallback decision-maker.

Is it enough?

Would that be all that needs to work in order to distribute autonomy? Especially when we talk about the most radical way of doing it (remember, anyone can make any decision).

Surely not.

And I’m happy to be challenged. We most likely have a good answer to that. We have been using this system for 12 years, and it’s doing just fine.

If I learned anything during that time, the most difficult parts are really not the ones people think. And the gain from everyone’s involvement and care is immense.

There’s been an interesting long-term study on graduates. Those who prioritized wealth and financial success in survey responses were significantly more likely to achieve it 20 years later. It seems almost intuitive, doesn’t it? Their choices, actions, and focus were likely geared toward accumulating wealth and maximizing financial gains.

This phenomenon isn’t confined to individual career paths. I’ve observed a similar pattern across organizations within our industry. It’s quite telling to look at the trajectory of companies over a decade or more.

Some organizations have had a laser focus on growth, and subsequently, they’ve experienced remarkable expansion. Others have chased public recognition and local fame, their representatives becoming well-known figures in relevant communities. Still others have invested heavily in technological excellence, attracting top-tier engineers.

The intriguing part is this: often, you could predict these outcomes simply by understanding the priorities of the company’s leadership.

Why? Because leadership’s influence on an organization is immense. Their personal aspirations become the organization’s goals. Their decisions, consciously or subconsciously, are often optimized to serve their own individual objectives. It’s no surprise, then, that an organization’s achievements frequently mirror the priorities of its leadership – much like the undergraduates in the study.

This observation, by the way, also translates to the prevalent issue of short-term thinking in the corporate world. After all, the top leaders are typically manipulated to “increase value for their shareholders” with hefty rewards. But that’s a discussion for another time.

Acknowledging the above, here’s a valuable tip: before partnering with any company, try to understand what truly motivates its top leaders. Not what they say officially on their website or in the materials they send you.

Find who’s on the very top of the organization and do a little bit of research. Heck, ask AI to do it for you if you can’t get a report from someone working directly with them. And if you can get them to talk to you, it’s a home run.

Ideally, get them to articulate their priorities, values, and beliefs. That should be easy, especially when dealing with a smaller organization. This insight will be a telltale of how your collaboration will look like.

You’ll gain a picture of how you, your company, your product, and your goals fit into their agenda. That fit should be a critical factor when choosing a technical partner, business collaborator, or, really, anyone in whom you want to invest loads of money.

Looking back on my 13 years at Lunar Logic, every long-term collaboration we’ve forged serves as a testament to this principle. Our (often unspoken) priorities were consistently aligned with those of our clients and partners.

And if there’s one reason to explain our record 17-year-long (and counting) collaboration with one client, it’s precisely this match. By the way, not only is it the longest gig in the history of Lunar, but also, hands down, the best client we could have dreamt of.

Coming back to Lunar’s focus, it’s never been on rapid growth, widespread fame, or even undisputed technical superiority.

We’ve been this crazy company that decided to experiment with radical organizational culture. We have no managers. Anyone can make any decision (in a structured way, of course). By many accounts, we are rebels.

Does it work, though?

I bet Michael, who has collaborated with us for 17 years, would confirm. And he’d be far from the lone example on this account.

People stay at Lunar for over twice as long as the norm in our niche suggests. So, it’s another voice that we do something right.

But walking the talk, if you want to get an accurate picture of whether there’s a match, let me know. In the spirit of transparency, which is one of our values, I’m happy to share a lot about Lunar.

Then, it’s anyone’s choice whether we are a good match or not.

Some time ago, I had a lengthy exchange about how we work at Lunar Logic, which behaviors are OK and which are not. At one point in the discussion, I realized that the source of the different stances in the dispute was a very different perception of what organizational culture is.

Organizational Culture

When I’m referring to organizational culture in my presentations and writing, I typically use quotes from Wikipedia.

“Organizational culture is the behavior of humans within an organization and the meaning that people attach to those behaviors.”

“Culture includes the organization’s vision, values, norms, systems, symbols, language, assumptions, beliefs, and habits.”

Interestingly enough, over the years the exact phrasing of Wikipedia article on organizational culture has evolved so you won’t find identical words there anymore. Either way, the original quotes stand the test of the time.

If you need a more concise definition, I could propose something like “a sum of behaviors of everyone in an organization, or a part of it, and the reasons behind these behaviors.”

Even shorter: “how everyone in a group behaves and why.”

Building Blocks

From the perspective of a person who wants to learn an organization or to influence the culture shift, not all the building blocks are equal. It is near impossible to change people’s fundamental beliefs or core values. It is neither easy nor fast to alter subconsciousness. Habits, assumptions, and perceived systems often reside in the subconscious part of our thoughts.

What’s more, all of the above, except for some habits, aren’t easy to spot. Ultimately no one has their core values tattoed on their forehead, and very rarely we are aware of these inner drivers of others’ behaviors. It’s no wonder. No one teaches us to pay attention to that.

The most visible aspects of culture, and thus, the easiest to work with, are rules and norms, respectively. Rules, by definition, should be written down, so they are accessible to anyone interested. Norms are a bit trickier since they’re defined by what people believe is, or is not, appropriate. Either way, if one pays attention, it is not hard to derive organizational norms by merely observing what people do and what they do not.

The Role of Observation

Let’s assume that you’ve just joined a new company. You enter our office cantina and see me having a beer with my lunch. You realize that there was nothing about that in the rule book you read during the onboarding. However, a societal norm is that we don’t drink alcohol during work hours. How do you react? Most likely, you look at other people to probe their reactions. If they ignore my behavior altogether, it appears that it is OK for me to have a beer during lunch.

Note: it’s too little to tell what the norm is yet. It’s a decent first step, though. You may still want to watch whether other people do the same thing or instead I am a special case, and I can do things others can’t. Oh, and it may be relevant whether a beer was a regular or non-alcoholic one.

Either way, eventually, you have a good sense of whether you (or anyone else) can safely have a beer for lunch. You will derive that knowledge by merely observing and absorbing the environment around you.

Observation is indispensable too in the context of rules. Something can be written down as a rule and still get ignored. We could tweak the story above so that there is a rule, e.g., in the employment contract, that explicitly states that drinking alcohol at work is forbidden. This way we’d have a situation when a norm (having a beer with lunch is fine) contradicts a rule (it is prohibited).

The outcome would be the same altogether. The norms trump the rules. Without observation, it is neither possible to figure out the norms nor to learn which rules are there in the name only and which are the law.

Figuring Out Organizational Culture

If one aims to understand the organizational culture of a company they just joined, there is no real shortcut that would be an equivalent of prolonged observation. Some tricks may hasten the process, of course. Not too much, however. You can’t learn the organizational culture in several weeks. At best you can familiarize some parts, but it would be far from a complete picture.

Again, let’s imagine that you’ve just got hired. You joined a team of five, which is a part of a division of 40-something, and the whole company is around 200 people. Figuring out how to safely operate and behave in the closest neighborhood — your atomic team — should be a straightforward process. You’ll get plenty of opportunities to observe, and feedback loops will be short. You’ll have validation paths readily available through the means of chatting with your team lead and your peers.

This way, you would explore, however, only one small area on a big map of organizational culture. Yes, it is by far the most important for your everyday work, but hardly enough for a complete understanding of how to act in all situations, including some that may get you fired.

There are interactions within your division, both cross-team and division-wide. There are all sorts of rules and norms that apply to a company as a whole, or specific ranks, or even particular people. Discovering all these uncharted areas takes time.

The Tricks

There are a few tricks that can speed the exploration a bit. By no means, they are a substitute for awareness and observation, but they help.

The higher up in the hierarchy someone is, the bigger their influence over the culture. To get a roughly accurate, even if a vastly incomplete and imprecise, image of the organizational culture, you could shadow the company’s CEO for some time. Since the behaviors of higher ranks often get copied at lower levels, a sneak peek at the very top of the hierarchy gives you a potentially most statistically significant representation of the culture.

Ignore officially expressed company values, its vision, or a mission statement. It is such a rare case that a company indeed follows an aspiration expressed in either of them that they most usually are a source of noise, not signal. Look at the actual behaviors, not aspirational statements.

Seek conflicts and watch how they get resolved. Controversial situations require parties to take a stand, and thus, they trigger action. On such occasions, it is easy to see who calls the shots and whose opinions count. The friction that is an integral part of any conflict is a natural fuel for shaping and reshaping norms, challenging rules, and expressing less visible drivers of the culture: values, beliefs, and assumptions.

Ultimately, though, there’s no better trick than patience and perceptiveness.

Crucial Role of Understanding Culture

OK, but why is understanding the organizational culture so important? Unless we have a good grasp of it, we are bound to either traveling only through well-beaten paths or risking frustration.

Well-beaten paths are safe. It’s easy to follow what everyone else is doing. It means, however, that our influence on the organization would be limited to the face value of our everyday contributions. We wouldn’t be challenging or changing our team and our company. Typically, that’s perfectly fine, even expected, during an initial period at any organization. Later on, not necessarily so. At least not in a firm that hopes to use the potential of its people.

The other scenario is quickly jumping to the acting mode, challenging rules, status quo, opinions, behaviors; it’s a departure from a beaten path. The problem is when such a departure happens in uncharted territory. There are things which are appropriate and those that are not. There are norms, beliefs, assumptions, and values. Blindly flailing around means that we would inevitably violate these informal constraints.

This way we will, of course, uncover the part of the uncharted territory, but the price is high. One part of it is frustration: “Oh, we don’t do such things here; I wasn’t aware.” The other part is reputation. Opposing or challenging things with little effort to understand them first doesn’t score much respect. There is a world of difference between being a contrarian who understands the culture and one who doesn’t.

If we aspire to influence organizational culture eventually, learning it first is a crucial and obligatory prerequisite.

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.

There is a remark on hiring I’ve heard quite a few times recently. It’s about sending a rejection message to a candidate. It goes along the lines: “Just don’t tell them that they’re not a good fit for the culture. That’s bullshit. That means nothing.”

A Bad Fit

I can’t say that such a remark lands well with me. I do, however, understand where it is coming from. As the industry, we started paying attention to the culture. It’s on our radars. We may have only a vague understanding of what organizational culture is but it is already a part of the discourse. This vagueness of understanding of the concept actually comes handy when there’s no tangible reason to reject a candidate but we still somehow didn’t like them.

They are a bad cultural fit.

Whatever that means.

See, the problem I have with many of these statements is that they’re used as a bludgeon without much thought invested to why “we didn’t like” a candidate. Because of that we often throw the baby out with the bathwater.

A Good Fit versus Likability

When hearing about lack of cultural fit I often follow up ask what it means that a candidate wasn’t a good cultural match. The answer, most often, is something like “that’s a person we wouldn’t get on well with”, or “that’s not a person I’d like to hang out with”, or “it’s not my kind of a person”. These boil down to how likable a candidate is for an assessing person.

The problem is that likability is a terrible way of assessing cultural fit. Not only is it not helpful, but it is also counterproductive.

If we chose likability as our guiding principle to judge cultural match we would end up with a group of people similar to each other. They’d have similar interests, many shared views and beliefs, etc. We would be building a very homogeneous culture. An echo chamber.

Sure, there wouldn’t be much conflict in such a group. There wouldn’t be much creative thinking either. There would be premature convergence of the ideas, little scrutiny, few alternative options would be explored.

If we consider knowledge workers such a team would have appalling performance. Thus my problem with such a shallow understanding of cultural fit.

Shared Values, Diverse Perspectives

So what is an alternative? How to define cultural fit in a way that would yield a high performing team? General guidance would be to optimize for representation of different, diverse points of view while creating an environment where people are encouraged to contribute.

These two ingredients—diversity and enabling environment—balance each other in a way.

We want diversity to have an option to learn about other, non-obvious ideas. Such ideas won’t come from people similar to ourselves. We thus want to have a range of different people in a team. And when I say “different”, I think of different walks of life, different experiences, different beliefs, different preferences, different characters, etc. This might be translated to maximizing diversity.

However, diversity for the diversity sake is not the way to go. This is exactly where the second part kicks in. We want to sustain an environment where people share their diverse opinions, and not simply have them. For that to happen we need to have a common base that encourages people to feel comfortable enough to contribute.

That common base is a set of shared values. I won’t give you a list as I don’t believe there’s the way. There are many ways to build such an enabling environment. There are, of course, usual suspects: respect for people, emotional safety, or autonomy, just to mention few. The important part is that such a set of shared values provides an informal, and typically implicit, contract that makes it safe to contribute.

Cultural Fit

With that founding principle, the definition of a cultural fit would be very different. A good match would mean that we share core values but beyond that, a candidate is as different from current team members as possible.

This means that friction will happen. Conflict too. Not everyone will feel comfortable all the time and not everyone will be getting on well with everyone else.

This means that when we decide there isn’t a good fit we may come up with a much more tangible explanation why. It is because we don’t share values—e.g. we perceive a candidate as disrespectful—or we don’t sense any aspect in which a candidate would stretch diversity of the team in one of the desired dimensions.

Note: not all dimensions of diversity are equal. There’s little, if any, value in my experience as a sailor in the context of product development. There’s more value in, say, cognitive studies that someone else went through. That’s why I add a quantifier “in the desired dimension” next to “diversity”.

Some time ago at Lunar Logic, we rejected a candidate for a software developer role whose focus was purely on their technical skills. There’s nothing wrong in that of course unless this is the only dimension a candidate uses to look at themselves and at others. There was some mismatch in shared values, e.g. little understanding and appreciation for teamwork and collaboration. We didn’t see much diversity that they would add to the mix either—we already have quite a bunch of excellent developers.

Interestingly, the decision was made despite the fact that we liked the candidate and were getting on well with them. That’s a complete opposite of what a naive approach to cultural fit would suggest us to do.

We believe that we are better off with that decision. More importantly, we believe that the candidate will be better off too. As long as they find a company where there’s a better overlap in shared values not will they contribute more but will also be appreciated better.

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.

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.