Pawel Brodzinski on Leadership in Technology

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

Author: Pawel Brodzinski

  • 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.

  • Lack of Autonomy: The Plague of the Modern Workplace

    Radical Self-Organization is a way I tend to label organizational design that we adopted at Lunar Logic. It’s been dubbed The Lunar Way too on occasions. Anyway, it draws from different approaches to design organizational structure in a very flat, non-hierarchical way. Describing what we do is probably worth a separate post on its own, yet this time I want to focus on one underlying principle: autonomy.

    Our evolution toward Radical Self-Organization was experimental and emergent. Initially we didn’t set a goal of distributing authority, autonomy, and all the decision-making power across the whole organization. It emerged as a sensible and possible outcome of further evolution on the path we set ourselves onto. This means we were figuring out things on our way and quite often explored dead-ends.

    The good part of such approach is that, we wanted it or not, we needed to understand underlying principles and values and couldn’t just apply a specific approach and count on being lucky with the adoption. No wonder that on our way we had quite a bunch of realizations what was necessary to make our effort successful.

    One of the biggest of such realizations up to date for me was the one about autonomy.

    A traditional, hierarchical organizational structure that distributes power in a top-down manner is ultimately a mechanism depriving people of autonomy.

    Let me explain. Top-down hierarchy addresses challenges of indecisiveness and accountability. We ideally always know who should make which decision and thus who should be held accountable for making it (or not making it for that matter). So far so good.

    The problem is, that the same mechanism discourages managers throughout a hierarchy to distribute the decision-making power to lower levels of organization. After all, if I am held accountable for a decision, I prefer to make the final call myself. Even if I end up being wrong it’s my own fault and I don’t suffer for mistakes of others, i.e. my team.

    In short, as a manger in a traditional structure I’m incentivized to double-guess and change the decisions proposed by my team even if I go as far as consulting my calls with the team. In other words, I am discouraged to distribute autonomy.

    This has fundamental consequences. Autonomy is a key prerequisite of being motivated at work. Lack of motivation and disengagement is a plague at modern workplace. In 2013 Gallup reported that worldwide only 13% of employees were engaged. We can’t expect our team to be creative, highly productive and responsive to ever-changing business environment when they simply don’t give a damn.

    And it’s not teams’ fault. We create systems where autonomy, and as a result engagement, simply is not designed in.

    It’s not managers’ fault either. We set them up in a structure where they are punished for distributing autonomy.

    The biggest problem is that hierarchical structure is a prevailing management paradigm, which we are taught from the earliest contact with the education system. The very paradigm is the plague of the modern workplace.

    There is one important side note to mention here. Autonomy doesn’t equal authority. The two works well as a pair but neither is a prerequisite to have the other.

    I can give people authority to make project related decisions, e.g. that we terminate collaboration with a client. They can formally do it. However, if I instill enough fear of making such a tough call so that everyone is too afraid to do so people won’t have autonomy to make such a decision.

    On the other end, we may not distribute authority formally, but we may live up to the standards of “what’s not forbidden is allowed” and may believe that “it’s easier to ask forgiveness than it is to get permission”. In such an environment people will be making autonomous calls even if they don’t always have authority over the matter.

    Coming back to the argument about disengagement, it’s about lack of autonomy, not lack of authority. In other words, simply giving people power to make some decisions won’t solve the issue. It’s about real autonomy, which unfortunately is so much harder to achieve.

    If we agree that lack of autonomy is the problem we have quite an issue here. Since the root cause of the problem goes as deep as to the way we design organizations. Changing how we think about the domain is a huge challenge.

    The other day I was reading an article that mention a guy who opened a branch office in another city and let it run as a Teal organization with no managers and huge autonomy. His summary of his own story was something along the lines: there are 30 people with no management and they are doing great, but I think by the moment there are 50 of them we’ll hire a director.

    This shows how strongly we are programmed to think according to old paradigm. It’s like saying “it’s going great, let’s kill it because, um, my imagination doesn’t go as far to imagine the same thing in a slightly bigger scale.”

    It also shows how big of a challenge we are about to face. Simply changing how the power is distributed in an organization won’t do the trick. Unless such a change is followed with the actual change in power dynamics, enabling autonomy in lower levels of an organization it would simply mean paying a lip service. The most difficult change that needs to happen to allow for such a transformation is the one happening in the mindset of those in power, i.e. managers.

    That’s bad news. If we consider power as privilege, and I do perceive it so, it means that many managers would be oblivious to the notion that they are somehow privileged over others. It means that we first need to work on understanding of domain. Once there, there’s another challenge to face: giving up the privilege. It can’t just be done by setting up different roles. That would be simply distributing authority and that is not enough.

    The real game changer is distributing autonomy: the courage to make decisions even when—especially when—a decision would go against manager’s judgement. After all, the plague of the modern workplace is not lack of authority, but lack of autonomy. Without addressing it we should neither expect high motivation levels nor high engagement.

  • Teal is the New Black

    On many occasions, I’ve shared how we operate at Lunar Logic. We exploit radical transparency—every single bit of information is available to everyone at the company. We exercise radical autonomy—everyone can make any decision on the company account. We entertain radical self-organization—there’s no enforced structure or hierarchy, there are no managers, and the CEO role is purely titular. While it sounds extreme when you hear about it, it feels even more so when you live it.

    Given that we went through a transformation from a rather typical organizational structure, we very well understand how many mistakes one can make when introducing such an organizational model. After all, we made great deal of them ourselves.

    We didn’t use any of the labeled models when approaching our evolution. We are, however, very frequently dubbed as a Teal organization, as described by Frederick Laloux in his book Reinventing Organizations. I don’t necessary fancy the label as I’m not overly fond of the model proposed by Laloux. Nonetheless, the label is somewhat useful to communicate how we are organized at Lunar.

    The interesting thing is how people react to Lunar Logic story. Over time I get more and more reactions like “oh, we’re working exactly the same way” or “yeah, we are Teal too”. This often triggers some questions on my end. Do you have transparent salaries? How do you set salaries? Do people know the contract details? How much company money can people spend without getting a permission? Can people leave the project they’re on when they want to? How is the strategy decided? Which decisions can be made by high-ranks only?

    Inevitably, most of the answers are as expected. “We can’t let people decide to spend company money at their whim, let alone set their own salaries. That would ruin the company! We can’t even let people know what everyone else earns as it would trigger huge frustration. And obviously strategy, and many other important decisions, are prerogative of senior managers.”

    Other than that, you are perfectly Teal, aren’t you?

    Progressive Organization is an umbrella term I use to describe different modern approaches to redefine how organizations are designed. Declaring that a company is one of flavors of Progressive Organization became a fashionable thing. People aspire to have flat-structure organizations, and to empower people (which is a completely flawed goal by the way). When it comes to labels, Teal organizations are getting most of the buzz these days. It’s a trendy thing to say that an organization is Teal or at least aspires to be so.

    Teal is the new black.

    The problem is that little comes afterwards. Transforming an organization from a traditional, hierarchy-based model toward radical self-organization and radical autonomy (both being crucial parts of becoming a Teal organization) requires lots of changes.

    I don’t necessarily say that fully transparent salaries, salaries set by employees themselves, freedom over choosing what people work on, no permission expected to spend significant amount of company money, or all the authority distributed to everyone at the company are all required to dub a company a Progressive Organization. I do say that, in one way or another, the way all these decisions are made need to be reinvented to be more inclusive for everyone at the company.

    In most cases the disputed companies have no will whatsoever to challenge the old operating system where managers make vast majority of the important decisions. I even heard people explicitly stating that they were “somewhat Teal” and had “no will to become more so”. Why would they even refer to the label then?

    Because Teal is the new black.

    If I counted companies whose representatives declared that they work in a similar way to Lunar or that they are Teal I should be over the top. After all, I’m somewhat pessimistic about the pace at which the organizations would evolve away from the old, entrenched, century-old, hierarchy-based management paradigm. The reports I keep hearing should be a proof that the situation is far better than I thought.

    I stay skeptic, though. The reason is that most of the reports are about Progressive Organizations in the name only. Hearing the stories, I’m not comfortable with as little as saying that it’s their genuine aspiration to evolve into a new organizational design. I would rather describe it as a pretense, and the one introduced on the weak grounds of fashion.

    The outcome will be two-fold. On one hand we already see inflation of the commonly used terms, like Teal. When someone says “Teal” it means less and less over time as it’s used to describe lots of different things. It wasn’t a precise term to start with and the more popular it is the faster the watering down process is. It is the fate that awaits any niche concept that hits the mainstream. The term Agile is a canonical example. These days it is used to label pretty much anything.

    Personally, I don’t care overly much about this effect, though. After all, I don’t have any stakes in promoting Teal.

    I do care about the other effect and I believe it will be positive in the long run. Given increasing popularity of the idea, even without implementing it the proper way, we can expect that more and more people would become aware of alternative organizational models. While in the short run I still see little action to truly transform companies, awareness is something that will provide leaders and managers with options in the long run.

    At the beginning of our way at Lunar we were inventing lots of things ourselves. There was limited literature about alternative models and none of us was into what was available. There were few stories of progressive companies, even though they exist at least since fifties. We didn’t know much where we were headed or what the desired endgame looked like.

    Awareness of what is possible, makes it easier to plan the change. With increasing number of available stories of different Progressive Organizations, there is plenty of inspiration to design own model and run own experiments. In the long run this fashion will, I believe, have a lasting effect on how humane our organizations are. In the even longer run it will hopefully affect whole industries.

    That’s why on one hand I treat Teal as a label that often bears little value but I’m happy that it makes its way to common awareness. In a way I’m happy that Teal is the new black.

  • Can One Be Too Respectful?

    Some time ago, during our weekly Lean Coffee at Lunar Logic, which is the only all hands meeting at the company, I made a disrespectful comment. It was a topic which I have a strong opinion about. A particular example that was brought to support one argument triggered a visceral reaction on my side. I said more, and more emotionally, than I should have.

    A day after I asked people for feedback to understand better what had happened and how I could avoid crossing the line in future. The recurring theme was that the way I expressed myself, both the words and the form of my remark, was disrespectful to some.

    That triggered another discussion some time later, and in a smaller group. It was about the meaning of being respectful and its implication of our behaviors in all sorts of situations.

    We started with an assumption that being respectful means acting in a way that doesn’t hurt others intentionally. But hey, there’s the whole unintentional spectrum of effects. Luckily, we are pretty good at sharing feedback and being transparent in front of each other. This means that when someone unintentionally crosses the line it is likely that they will hear a comment referring to that behavior being disrespectful.

    Going forward, with such stuff a natural desire is to be on a safe side. In other words, if I have doubts whether saying something would be disrespectful to someone I should not say that. It’s a safe choice.

    And that’s exactly where we started questioning ourselves. Doesn’t our aspiration to be respectful affect how we act in less obvious situations? Doesn’t it mean that we restrain critique, harsh words, or confrontation even when we believe that they would otherwise be justified? Doesn’t we restrain ourselves from being authentic?

    As a matter of fact, there can be two different sources of such a restraint. First, someone may be worried that criticism or confrontation itself would be received as disrespectful. After all, we are subjective; we may have opposite points of view and we can only control how we express our thoughts, not how they are received by the other party. We may do as much as we can to talk and behave in a respectful way but ultimately we can’t control how our attitude and behavior will be interpreted.

    Second, and more importantly, most of us has neither enough skill nor practice to be able to react in such a respectful way contextually. Even if we could succeed given that we prepare, e.g. when sharing difficult feedback, we would fail to act similarly when caught off guard, e.g. in an unexpected discussion about a topic we have a strong opinion about. And I don’t use it as an excuse. I make a simple observation in the spirit of starting with what we have.

    Now, if being respectful is our guiding principle we may choose not to speak up, rather than risk hurting someone. That would mean that we suppress conflict, feedback and idea cross-pollination. That would mean that we suppress our development both as individuals and as an organization.

    The question we were staring at was: can we be too respectful?

    Can we bring respect to the level when it is not justifiable anymore? Can being respectful yield unwanted outcome?

    Intuitively my answer was negative. And yet I couldn’t discard the argument as a whole since I’ve experienced the dilemma myself.

    The thing is that respect is a nuanced thing. The same behavior may be perceived as respectful by one person and as disrespectful by someone else. The same behavior may be perceived either as respectful or as disrespectful by the same person depending on whose behavior we put under scrutiny. The context matters. The group setup matters. The mood matters. And the list goes on and on.

    In a way, we can’t design a set of behavior that would be universally respectful. Well, not unless we are really,really far on the safe side. This, as we already established, would have some unwanted outcomes.

    And yet one of these catchy phrases I picked from Stephen Parry kept my mind working.

    Showing respect for people does not mean you have to like them, agree with their views, or fail to challenge any half-baked reasoning they may have.

    My thoughts were that we might have been using “respect” in overly broad way, like a wall shield rather than a buckler. However, I couldn’t wrap my head around something that would provide some guidance where the line should be. After all, Stephen’s remark focuses on what respect is not and not on what it is.

    Then I came across the following passage from Ray Dalio:

    Make sure people give more consideration to others than they demand for themselves.

    It is more inconsiderate to prevent people from exercising their rights because you are offended by them than it is for them to do whatever it is what offends you. That said, it is inconsiderate not to weigh the impact of one’s actions on others, so we expect people to use sensible judgment and not doing obviously offensive things.

    This principle, in a neat way, connects the dots in both directions and through that it addresses the risk of being “overly respectful” through suppressing oneself. It creates responsibility on each party involved in an interaction.

    A party that is about to do something that may potentially be disrespectful is bound to use sensible judgement and assess whether such a behavior can be commonly perceived as offensive.

    The other party, on the other hand, takes responsibility of using “the respect shield” sparingly, as if it was a buckler protecting the most sensitive areas and not a wall shield covering from literally everything.

    This way we create some sort of a middle ground when it comes to respect. We don’t call out all behaviors that can potentially be perceived as disrespectful. We don’t even call out some that touch us personally, assuming good intentions and acknowledging that people have different standards. What we gain thanks to that is an environment where there is a space for more contributions from everyone.

    There’s another consequence. Such a notion of respect, which accepts more behaviors, means that when someone calls “disrespectful” it is a strong signal that the line has been crossed. After all we may assume that such a call was considerate and took into account that suppressing someone else without a good reason is disrespectful too.

    Of course, maintaining the balance doesn’t come for free. It requires consideration. On one hand there’s a risk of extending that middle ground of consent too far. It would happen when we start accepting behaviors that are hurtful. On the other hand there’s a risk of shrinking that space too much. It would happen when we give less and less slack to others when they act out.

    The principle, however, provides us with a pretty good reference point: give others more consideration that you expect for yourself. That’s how we can avoid being both disrespectful as well as suppressing ourselves in a fear of being overly respectful.

    Should I know this principle I wouldn’t have said as much in the situation that kicked off this whole thinking process. Yet still I would still make my point strongly, even at the risk of other party feeling attacked by the strong statement. And that would probably have been the best possible outcome.

  • 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.

    emergent purpose

    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.

    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.

    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.

  • Autonomy and Authority

    These days I speak extensively about how we designed Lunar Logic as an organization. After all, going through a transition from a traditional management model to a situation where company has no managers at all is quite an achievement. One of the pillars of managerless organizational design is autonomy.

    After all, decisions won’t just make themselves. Someone has to call the shots. Once we got rid of managers, who would normally make almost all decisions, we need everyone else to embrace decision making. For that to happen, we need to distribute autonomy.

    Interestingly enough, when Don Reinertsen, who I respect a lot, talks about decentralizing control he uses somewhat different wording.

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

    Don Reinertsen

    Authority refers to a formal power to make a decision. However, I tend to make a clear distinction between authority and autonomy. Ultimately, as a manger, I can give my team authority to make a decision. However, at the same time I can instantiate fear or pressure on decision-makers so before they actually make their call they would ask me what I think about the topic and go with my advice. This mean that even if authority was distributed autonomy is not there.

    Corollary to that, I may not have formal authority but I can feel courageous enough to make a decision. If that is an acceptable part of an organizational culture it means that I may have autonomy without authority. By the way the latter case is interesting as it pictures the attitude I’m very fond of: ask forgiveness rather than get a permission.

    I’m not going to fundamentally disagree with Don Reinertsen, though. As a matter of fact, we are on the same page as he follows up with his train of thought.

    To enable lower organizational levels to make decisions, we need to give them authority, information, and practice. Without practice and the freedom to fail upon occasion, they will not take control of these decisions.

    Don Reinertsen

    In the first quote Don is talking about prerequisites to decentralize control. In the second he focuses on enabling it. He adds a crucial part: people need to practice. This, as a consequence, means that occasionally they will fail, a.k.a. make bad decisions.

    And that’s exactly what autonomy is in its core.

    In vast majority of cases autonomy is derived from authority. It doesn’t work the other way around, though. In fact, situation of having formal authority but no real autonomy to make a decision is fairly common. It is also the worst thing we can do if we want people to feel more accountable for an organization they’re with.

    Not only do they realize that the power they got is virtual but once it happens they’re not even back to square one. It’s worse. They got burned. So they’re not jumping on that autonomy bandwagon again when they are asked to get more involved in decision making.

    That’s, by the way, another case that portraits that cultural change are not safe to fail.

    Long story short, don’t confuse authority with autonomy. If you really care about your organization take care of distributing both, not only the former.

  • Organizational Culture and Hand Cream

    The other day we had a brief discussion at Lunar Logic on an idea that the company should provide hand cream for us. While normally we don’t really discuss such petty expenses, this time quite a few people got involved.

    One could say that the discussion itself cost the company more than a stash of hand cream that would suffice for several years. And they would be right.

    Why was I involved then? And why would I write about it afterwards?

    The thing is we don’t make decisions in isolation. Of course we can look at any decision in individual context. It’s all about hand cream and several dollars, right?

    Not really. Or at least not only. The meta-decision that was being made was about what is the extent to which the company provides its employees with stuff. It was about setting, or rather resetting, what benefits are available.

    Of course, at any company there are things that almost everyone would use, like coffee and tea, paper towels etc. These are no-brainers.

    But then, very quickly we enter the land of less obvious options. Like a hand cream. Ultimately not everyone would be using it. I’m betting around half of people maybe. So we’re making a small nice gesture to some.

    The question is: should we be making such small nice gestures to other groups?

    We have quite a bunch of people who are cooking lunches at the office. Should we buy cooking oil for them? Or spices? These would all be small expenses after all.

    So how about free food available at the office? Well, given that we have a couple vegans, healthy load of vegetarians, some burger lovers, a diabetic, a couple people on gluten-free diet and a couple more trying to lose a few pounds there would always be someone left out. These aren’t obvious decisions anymore.

    These kind of calls are really about deciding about where we set the limits. What is acceptable. It’s not about hand cream. It’s about what rationale would be enough to justify an expense on the account of the company. We are talking about norms.

    Have I just said “norms”? Oh well, it seems we are talking about organizational culture now.

    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

    Wikipedia

    Simply put organizational culture is a sum of behaviors of everyone in an organization. Not only behaviors themselves, though, but also what drives these behaviors: shared values, common principles, rules and norms.

    This is why I got involved in the discussion about hand cream. The trigger was realization that we are just about to change a norm and I’d rather have an explicit discussion about that beforehand. Such a change may affect the common attitude from “we’re not doing such things here” to “yeah, we’ve seen that happening before so it’s OK.”

    What’s more, giving all sorts of benefits away is not something that can be taken back seamlessly. As Daniel Kahneman in his profound book Thinking Fast and Slow points we think differently about something that we gain than about something that we lose.

    In other words getting hand cream is all fine and nice but almost instantly it becomes a new norm that hand cream is there. We’ve just set new expectation level. Once we stop supplying cream we would perceive that as a loss. The cost of removing a benefit would be bigger than a gain we got from introducing it.

    That’s why we can’t label changes that affect organizational culture as safe to fail. Like in: let’s try the hand cream thing and if people don’t care we’ll just stop buying it. When we are touching organizational culture there’s no rollback button. Even when we technically bring the situation back to the square one, culturally it’s different because we have a new experience so we look at things differently.

    That’s why I will get involved occasionally in discussions like the one about hand cream. And that’s why it was worth a blog post.

  • 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.

  • Value for Money

    There’s one observation that I pretty much always bring to the table when I discuss the rates for our work at Lunar Logic. The following is true whenever we are buying anything, but when it comes to buying services the effect is magnified. A discussion about the price in isolation is a wrong discussion to have.

    What we should be discussing instead is value for money. How much value I get for what I pay. In a product development context, the discussion is interesting because value is not provided simply by adding more features. If it was true, if the following dynamics worked—the more features the better the product—we could distill the discussion down to efficient development.

    For anyone with just a little bit of experience in product development such an approach would sound utterly dumb.

    Customers who will use a product don’t want to have more features or more lines of code but they want their problem to be solved. The ultimate value is in understanding the problem and providing solutions that effectively address it.

    Less is more mantra has been heard for years. But it’s not necessarily about minimalism, but more about understanding the business hypothesis, the context, the customer and the problem and proposing a solution that works. Sometimes it will be “less is more”. Sometimes the outcome will be quite stuffed. Almost always the best solution will be different that the one envisioned at the beginning.

    I sometimes use a very simple, and not completely made up, example. Let’s assume you talk to a team that is twice as expensive as your reference team. They will, however, guide you through the product development process, so that they’ll end up building only one third of the initial scope. It will be enough to validate, or more likely invalidate, your initial business hypothesis. Which team is ultimately cheaper?

    They first team is not cheaper if you take into account the cost of developing an average feature. Feature development is, however, neither the only nor the most important outcome they produce. Looking from that perspective the whole equation looks very differently, doesn’t it?

    This is a way of showing that in every deal we trade different currencies. Most typically, but not necessarily so, one of these currencies is money. We already touched two more: functionality or features and validation of business hypothesis. We could go further: code quality, maintainability, scalability, and so on and so forth.

    Now, it doesn’t mean that all these currencies are equally important. In fact, to stick with the example I already used, rapid validation of business hypothesis can be of little value for a client who just needs to replace an old app with a new one, that is based on the same, proven business model.

    In other words in different situation different currencies will bear different value for a purchasing party.

    The same is true for the other side of the deal. It may cost us differently to provide a client scalable application than to build a high quality code. This would be a function of skills and experience that we have available at the company.

    The analogy goes even further than that. We can pick any currency and look how much each party values that currency. The perception of value will be different. It will be different even if we are talking about the meta currency—money.

    If you are an unfunded startup money is a scarce resource for you. If at the same time we are close to our ideal utilization (which is between 80% and 90%) additional money we’d get may not even be a good compensation for lost options and thus we’d value money much less than you do.

    On the other hand, if your startup just signed round B funding abundance of available money will make you value it much less. And if we just finished two big projects and have nothing queued up and plenty developers are slacking then we value money more than you do.

    This is obviously related to current availability of money and its reserves (put simply: wealth) in a given context. Dan Kahneman described it with a simple experiment. If you have ten thousand dollars and you get a hundred dollars that’s pretty much meh. If you have a hundred dollars and you get a hundred dollars, well, you value that hundred much, much more.

    Those two situations create a very different perception of the offer one party provides to the other. They also define two very different business environments. In one it is highly unlikely that the collaboration would be satisfying for both parties, even if it happens. In the other, odds are that both sides will be happy.

    This observation creates a very interesting dynamics. The most successful deals will be those when each party trades currency that is low-valued for the one that is valued highly.

    In fact, it makes a lot of sense to be patient and look for the deals where there is a good match on this account than to jump on anything that seems remotely attractive.

    Such an attitude requires a lot of organizational self-consciousness on both sides. At Lunar Logic we think of ourselves as of product developers. It’s not about software development or adding features. It’s about finding ways to build products effectively. It requires broader skills set and different attitude. At the same time we expect at least a bit of Lean Thinking on account of our clients. We want to share understanding that “more code” is pretty much never the answer.

    Only then we will be trading the currencies in a way that makes it a good deal for parties.

    And that’s exactly the pattern that I look for whenever I say “value for money.”

  • Portfolio Management: Role of Autonomy

    I’m a huge fan of Real Options. Along with Cynefin, it is one of the models that can be very universally applied in different domains. No wonder that some time ago I proposed application of Real Options as a sense making mechanism that connects different levels of work being done in an organization.

    Simply put, potential work, be it projects or products, are options. We rarely, if ever, can effectively work on all the potential initiatives we have on our plates. That’s why we end up picking, a.k.a. committing to, only a subset of options we have.

    Each commitment to start an initiative instantly generates a set of options on a lower level of work. Once we commit to run a project there are so many ways we can structure the work and so many possible feature sets that we can end up building. We again have a set of options available and again eventually commit to execute some of them. That in turn generates the options on a layer or finer granularity work items, say individual features. It goes all the way down to the most atomic work items we have.

    Portfolio Management Real Options

    We need an accompanying mechanism to close a full feedback loop between the layers of work. We simply need to provide information back to the higher level of work. Think of situations like a project taking longer than expected. We obviously want that information to be taken into account when we are making commitments on a portfolio level. Ultimately, it means that available capabilities have changed and thus it influences the set of options we have on a portfolio level.

    Again, the similar dynamics will be seen between any of the two neighboring layers of work. Specific technical choices for features will influence how other features are built or how much time we’d need to make changes in a product.

    Portfolio Management Real Options

    The model can be easily scaled up to reflect all the layers of work that are present in an organization. In big companies there will be multiple layers of work even in the area of portfolio management only.

    The underlying observation is that we very, very rarely need information to be escalated farther than between neighboring levels of work. In other words a single feature that is late will not affect decision-making process on portfolio level. By the same token commitment to start a new project, as long as it takes into account available capabilities, will be of little interest to a feature team involved in an ongoing initiative.

    There is, however, one basic assumption that I subconsciously made when proposing this model. The assumption is about autonomy.

    Work flows down to the finer-granularity level is through a commitment at a coarser-granularity level. The commitment, however, is not only expressing good will that we want to build something. If we make a commitment to run a project we need to fund and staff it. The part of the commitment is providing people, skills and resources required to accomplish that project within expected constraints, be it time, budget, scope, etc.

    If there are other constraints that are important they need to be explicitly described once the commitment is being made. One example that comes to my mind would be around the ultimate goals for a product or a project. It can be about technical constraints – for whatever reasons technologies that a product will be built in may be fixed. Another common case would be about high level dependencies, e.g. between two interconnected systems.

    Such constraints need to be explicit and need to be expressed when the commitment is being made simply because they influence what options we will have in the lower level of work.

    There’s also another important reason why we want explicit constraints. When we move our perspective to a different level of work we also change the team that is involved in work. In the most common scenario the team context will change from PMO, through a project team to a feature team as we go down through the picture.

    And that’s exactly when autonomy kicks in. Commitment on a higher level of work generates options on a lower level. What kind of options we get depends on the constraints we set. These are all prerogatives of a team making decisions on a higher level.

    The specific choice among the available options, on the other hand, is responsibility of a team that operates on a lower level.

    Obviously, we don’t want PMO leader to tell developers how to write unit tests. That’s the extreme example though and I see violation of autonomy all over the place.

    Let’s start from the top. The role of PMO in such a scenario would be to pick initiatives that we want to run, a.k.a. make project- or product-level commitments. The part of the process would be defining relevant constraints for each commitment. These would be things like manning and funding the new initiative, sharing expectations deadlines, etc. This is supposed to provide fair amount of predictability and safety to the team that will be doing the actual work.

    One crucial part of defining constraints is making the goals of the initiative explicit. What we are trying to achieve with this product or project. In other words why we decided to invest time of that many people and that much money and we believe it was a good idea.

    And now the final part. Then PMO should get out of the way. Options are there in a product team or a project team. That team should have autonomy to pick the ones they believe are the best. Interference from the top will disable autonomy and as such will be a source of demotivation and disengagement. It is very likely that such interference would yield suboptimal choice of options too.

    The pattern remains the same when we look at any two neighboring layers of work. For example, we will see similar dynamics between a product team and a feature team.

    Portfolio Management Real Options Autonomy

    The influence on which options get executed happens through definition of constraints and not by enforcing a specific choice of options. Those different levels of work are, in a way, isolated between each other by the mechanism of commitment that yields options on a lower level, feedback loops going up and finally by distributing authority and maintaining autonomy to make decisions within own sphere of influence.

    Unsurprisingly the latter gets abused fairly commonly, which is exactly why we need to be more aware and mindful about the issue.