Pawel Brodzinski on Leadership in Technology

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

Tag: autonomy

  • Why Wouldn’t an Intern Fire a CEO?

    Why Wouldn’t an Intern Fire a CEO?

    The question seems completely wrong. Obviously, because they can’t. An intern could not possibly let go of a CEO.

    But what if they could? Would they? And if not, why?

    Right now, you may be thinking, “But Pawel, what do you mean by imagining an intern could fire a CEO? It’s a completely abstract problem.”

    It is not. In fact, at Lunar it is possible.

    Radical Autonomy

    I wrote about our radical way of distributing autonomy many times before. In short, anyone can make any decision (in a structured way). So why don’t people abuse that power?

    Why don’t I need to worry that an intern would launch a letting go process for me?

    And yes, they totally can.

    While this decision is somewhat more complicated than the vast majority of others, anyone has the authority to start this process. Including people who joined us yesterday.

    The Dynamic of the Organizational Culture

    Whenever we join a new group, we tend to be more withdrawn than whatever is our norm. That’s one of the basic social dynamics.

    First, we observe and learn. Subconsciously (or consciously), we look for patterns to understand the group’s norms. What’s acceptable? What’s not acceptable? What’s rewarded? What’s punished?

    We orient ourselves in a new environment.

    That’s precisely what happens in an organization when a new person joins. Even when rules as written say something, we observe whether it’s really so. After all, if rules contradict the norms, it’s the latter which prevails.

    No one will fire the big guns before they learn to navigate a new environment well.

    Peer Pressure as Safety Mechanism

    OK, but the same intern will still not fire a CEO 6 months later when they already learned the norms. Why?

    In a system based on distributed autonomy (again, anyone can make any decision; that’s the ultimate distribution), we have very different power dynamics.

    We don’t have a person in power entitled to make the call, that entitlement being the ultimate get out of jail free card. After all, there’s no one else to make that decision.

    In this case, anyone can act. But then, such a decision will be judged, challenged, commented on. If it’s controversial, let alone outrageous, people will be very vocal when opposing it.

    Through that, we introduced peer pressure as a safety mechanism that basically prevents the most extravagant decisions from being made.

    Reputation as Currency

    What follows is that whoever volunteers to make any decision makes a bet. A bet of their reputation. If the decision goes well, the bet is won.

    The more obvious the decision, the smaller the bet.

    After all, if everyone thinks something is a good idea, it’s unlikely that they’ll complain, even if it goes sideways.

    It’s a different beast altogether when the call is controversial. If I go against a big group, I better end up right, or my reputation as a decision-maker gets slashed.

    Before anyone’s ready to make such a bet, they must accumulate some of that reputation. Which means they will have been around long enough that we no longer talk about an intern firing a CEO.

    In fact, when someone is around that long, and they still want to fire me, well, they probably have some damn good arguments.

    By the way, if you’re interested, the most radical proposal coming from a fresh hire we’ve ever discussed was changing the salary system. Admittedly, a serious call, yet it didn’t even reach a stage where it was an actual proposed decision. The person gave up way sooner after receiving peer feedback.

  • Levels of Slack Time

    Levels of Slack Time

    I learned the meaning of slack time years back in the context of Kanban. Once we start managing workflow for effectiveness, we necessarily create these moments when we want to stop the work. Otherwise, we’d overload the bottleneck.

    When we design the slack time in the system, the natural question is, what’s next? How do we use it?

    The Use of Slack Time

    My first natural, although with the benefit of hindsight simple, answer was to optimize the teamwork.

    There’s always a colleague who would appreciate help. There’s always a stage of the process that no one loves (code review, anyone?). There’s always an improvement task that just never makes it the top priority (like paying technical debt back).

    Then, there’s a whole another context. Individual. Slack time creates a perfect opportunity to invest in oneself. Catch up with what’s new with technology (with the AI race, it seems like there’s something to catch up with almost every week). Learn something outside of the immediate context of the project. Sharpen one’s saw.

    But then, when we start considering the value of slack time in a more generic context, we realize that it goes way beyond the team level.

    Think of a fire station. Their whole system is designed around slack time. We don’t try to optimize the work for fire brigades for utilization. It would mean that we want firefighters fighting fires all the time.

    Thus, we’d either have an excess of fires or firefighters moonlighting as arsonists.

    Cross-Team Slack

    We can then abstract away the idea of slack time and consider how it applies in different contexts.

    The most basic context would be individual. Slack time helps me to get better.

    Going just a bit further, we have the team level. Slack time helps the team to become more effective. We achieve that either by coordinating around the ongoing tasks (short-term help) or working on improving the long-term performance (continuous improvements, paying technical debt back, etc.).

    So far, it’s all the basics. But what if we take another step into a broader context?

    Then we end up in cross-team/cross-project land. We start considering coordination problems. We look at interdependencies. We analyze an entirely different layer of work design.

    As much as we have a bottleneck within a development team (let’s say it’s testing), we will have one if we consider a cross-team initiative (let’s say it’s passing the security acceptance).

    Once we understand this high-level picture, we can use slack time to help the entire initiative become more effective. It’s likely that one team being able to deliver more features or deliver them more predictably will not move the needle of the whole product by a millimeter.

    The actual bottleneck may be in the design, or release, or even grand product-related decisions.

    That’s where cross-team slack time can be redirected. It would mean we’re asking the question: what’s the best way to help when I see the big picture?

    Organizational Improvements

    Can we go further up, though? Once we consider individual, team, and cross-team levels, is there more?

    But of course, there is.

    Once we strip the context from the product/project work, we look at the bare bones of any company—its organizational design. And there’s always plenty to do around these parts.

    At this level, we wouldn’t ask questions about improving my project/product. We’d look for ways to make the whole company improve.

    Think of any novel initiatives. Of course, “novel” is in the context of this company; I don’t expect us to routinely do world-changing stuff. Starting a self-help group. Running a new product experiment. Looking for fellow folks to challenge existing management paradigms. Opportunities are almost endless here.

    The more extravagant you become with the ideas, however, the less likely you’d be allowed to implement them. And here comes our culprit.

    Role of Autonomy

    We established different levels of slack time:

    • Individual
    • Team level
    • Cross-team
    • Organizational

    The further down that list you go, the bigger the potential impact of the changes. But most people wouldn’t even consider going beyond the team level. Why?

    Simplest answer? They don’t have enough autonomy.

    The degree to which we can impact our organization depends on our sphere of influence. And that is strongly correlated with how distributed autonomy is in any organization.

    It’s not binary, of course. It’s not that I can or cannot make a decision in a cross-team context. Sometimes, even when I can’t call the shots, I can influence the decision-maker.

    But if I don’t have autonomy on a team level, I shouldn’t expect to have influence on a cross-team level. Thus, we can use the autonomy distribution as our measuring stick.

    Limited Autonomy, Limited Impact

    Whenever I teach that stuff during workshops and university courses, I ask people a series of questions to assess how much their organizations distribute autonomy.

    The questions are separated into groups, roughly referring to the three levels mentioned above: team, cross-team, and organization. The outcome is the same every single time.

    We see a lot of autonomy on a team level. Teams can freely decide about many things. I think we have Agile to thank for that.

    But then, it breaks. Once we get to cross-team, the perceived autonomy goes from “significant” to “barely there.” And it won’t be a surprise that when we touch the organizational level, it’s non-existent.

    In such an environment, we shouldn’t expect to get that much out of slack time.

    So, the next step after introducing slack time to our systems is to get more autonomy in it as well.

  • (Non-)Challenges of Distributed Decision-Making

    (Non-)Challenges of Distributed Decision-Making

    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.

  • Autonomy and Transparency: Both or Neither

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

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

    That was totally not what happened.

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

    Ultimately, I got frustrated.

    Transparency without Autonomy

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

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

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

    Transparency without autonomy is a recipe for frustration.

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

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

    Autonomy without Transparency

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

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

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

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

    Don Reinertsen

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

    Transparency and Autonomy

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

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

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

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

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

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

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

    Moving the Bar

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

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

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

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

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

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

    Neither or Both?

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

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

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

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

  • Agile Self-Organization: Band-Aid for a Broken Leg

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

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

    All but the most micromanagerial types should be satisfied.

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

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

    History of Agile (Oversimplified)

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

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

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

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

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

    The Broken Leg

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

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

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

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

    The Band-Aid

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

    We know it’s not the case.

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

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

    The Cure

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

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

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

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

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

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

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

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

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

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