Author: Pawel Brodzinski

  • Care Matters, or How To Distribute Autonomy and Not Break Things in the Process

    Care Matters, or How To Distribute Autonomy and Not Break Things in the Process

    At Lunar Logic, we have no formal managers, and anyone can make any decision. This introduction is typically enough to pique people’s curiosity (or, rather, trigger their disbelief).

    One of the most interesting aspects of such an organizational culture is the salary system.

    Since we all can decide about salaries—ours and our colleagues—it naturally follows that we know the whole payroll. Oh my, can that trigger a flame war.

    Transparent Salaries

    I wrote about our experiments with open salaries at Lunar in the past. At least one of those posts got hot on Hacker News—my “beloved” place for respectful discussions.

    As you may guess, not all remarks were supportive.

    Comments about transparent salaries from Hacker News

    My favorite, though?

    IT WILL FAIL. Salaries are not open for a reason. It is against human nature.

    No. Can’t do. Because it is “against human nature.” Sorry, Lunar, I guess. You’re doomed.

    On a more serious note, many comments mentioned that transparent salaries may/will piss people off.

    The thing they missed was that transparency and autonomy must always move together. You can’t just pin the payroll to a wall near a water cooler. It will, indeed, trigger only frustration.

    By the same token, you can’t let people decide about salaries if they don’t know who earns what. What kind of decisions would you end up with?

    So, whatever the system, it has to enable salary transparency and give people influence over who earns what.

    Cautionary Tale

    Several years back, I had an opportunity to consult for a company that was doing open salaries. Their problem? Selfishness.

    In their system, everyone could periodically decide on their raise (within limits). However, each time after the round of raises, the company went into the red. All the profits they were making—and more—went to increased salaries.

    The following months were spent recovering from the situation and regaining profitability, only to repeat the cycle again next time.

    Their education efforts had only a marginal effect. Some were convinced, but seeing how colleagues aimed for the maximum possible raise, people yielded to the trend.

    The cycle has perpetuated.

    So what did go wrong? After all, they followed the rulebook. They merged autonomy with transparency. And not only with salaries. The company’s profit and loss statements were transparent, too.

    It’s just people didn’t care.

    Care

    Over the years, when I spoke about distributed autonomy, I struggled to nail down one aspect of it. When we get people involved in decision-making, we want them to feel the responsibility for the outcomes of their decisions.

    The problem is that we have a diverse interpretation of the word. I once was on the sidelines of a discussion about responsibility versus accountability. People were arguing about which one was intrinsic and which was extrinsic.

    As the only non-native English speaker in the room, I checked the dictionary definitions. Funny thing, both sides were wrong.

    Still, I’d rather go with how people understand the term (living language) rather than with dictionary definitions.

    So, what I mean when I refer to being responsible for the outcomes of one’s decisions is this intrinsic feeling.

    I can’t make someone feel responsible/accountable for the outcomes of their call. At most, I can express my expectations and trigger appropriate consequences.

    To dodge the semantic discussion altogether, I picked the word agency instead.

    The only problem is that it translates awfully to my native Polish. Frustrated, I started a chat with my friend, and he was like, “Isn’t the thing you describe just care?”

    He nailed it.

    Care strongly suggests intrinsic motivation, and “caring for decision’s outcomes” is a perfect frame.

    How Do You Get People to Care?

    The story of the company with self-set salaries—and many comments in the Hacker News thread—shows a lack of care for their organizations.

    “As far as I get my fat raise, I don’t care if the company goes under.”

    So, how do you change such perspectives?

    Care, not unlike trust, is a two-way relationship. If one side doesn’t care for the other, it shouldn’t expect anything else in return. And similarly to trust, one builds care in small steps.

    Imagine what would happen if Amazon adopted open salaries for its warehouse workers. Would you expect them to have any restraint? I didn’t think so. But then, all Amazon shows these people is how it doesn’t give a damn about them.

    And that can’t be changed in one quick move, with Jeff Bezos giving a pep talk about making Amazon “Earth’s best employer” (yup, he did that).

    First, it’s the facts, not words, that count. Second, it would be a hell of a leap for any company, let alone a behemoth employing way more than a million people.

    As I’m writing this, I realize that taking care of people’s well-being is a prerequisite for them to care about the company. And that, in turn, is required in order to distribute autonomy.

    The Role of Care

    The trigger to write this post was a conversation earlier today. We’re organizing a company off-site, and I was asked for my take on paying for something from the company’s pocket.

    Unsurprisingly, the frame of the question was, “Can we spend 250 EUR on something?”

    Now, a little bit of context may help here. Last year was brutal for us business-wise. Many people make some concessions to keep us afloat. Given all that, my personal take was that if I had 250 EUR to spend, I’d rather spend it differently.

    But that wasn’t my answer.

    My answer was:

    • Everybody knows our P&L
    • Everybody knows the invoices we issued last month
    • Everybody knows the costs we have to cover this month
    • Everybody knows the broader context, including people’s concessions
    • We have autonomy
    • Go ahead, make your decision

    In the end, we’re doing a potluck-style collection.

    Sure, it was just a 250 EUR decision. That’s a canonical case of a decision that can not sink a company. But the end of that story is exactly the reason why I’m not worried about putting in the hands of our people decisions that are worth a hundredfold or thousandfold.

    We’ve never gone under because we’ve given ourselves too many selfish raises. Even if we could. The answer to why it is so lies in how we deal with those small-scale things.

    After all, care is as much a prerequisite for distributed autonomy as alignment is.


    This is the third part of a short series of essays on autonomy and alignment. Published so far:

    Feel free to subscribe/follow here, on Bluesky, or LinkedIn for updates.
    I also run the Pre-Pre-Seed Substack, which is dedicated to discussing early-stage products.

  • The Role of Alignment

    The Role of Alignment

    In the first part of this series, I focused on why autonomy in a workplace is a critical ingredient if we want to stay relevant. Not only is it a response to the nature of everyday work, with the increasing significance of remote work and the rise of AI, but it is also an emergent outcome of the large-scale evolution of the economy.

    However, if there is a universal warning that should be attached to the advice suggesting decentralizing control, it should be the following.

    It’s never as simple as “give people more autonomy.” The way people act in a decentralized system depends on a broader culture, which one should consider before giving everyone more power.

    Purpose

    One common theme in the discourse on organizational culture is purpose. A shared theme that people and teams aspire to change into reality.

    By the way, when considering joining any company, I recommend asking about their purpose. In fact, I’d ask different people this very question and see whether their answers are aligned.

    “Making more money” is not a purpose. It’s a tactic. Ditto “increasing value for shareholders.” If you want to send a man to the moon, that’s a great purpose. But it doesn’t have to be that big. I’m a fan of honest aspirations like “creating a healthy workplace that sustains a few dozen employees and their loved ones,” too.

    Aside from its strategic role, or impact on motivation, purpose has a role in the discussion about autonomy. It is the force that encourages alignment of all the efforts happening in an organization.

    Misalignment

    Imagine a company guided by the “making more money” aspiration. People would naturally see different, sometimes contradicting, ways of generating revenues. They’d be pulling in different directions.

    Using a physical metaphor, we could consider a circle as the whole organization and arrows within as different individuals pursuing different goals.

    Low autonomy and low alignment impact on organizational momentum

    All those forces combined would create some momentum. The company would be slowly moving wherever the push is strongest.

    What would happen if we gave people more autonomy in such a setup? It is the equivalent of giving every individual more influence over the whole company. Each force vector would become stronger.

    High autonomy and low alignment impact on organizational momentum

    Now, everyone has better leverage, but the combined effect on the organizational momentum is marginal. The reason is obvious. It’s all the contradicting priorities. People try to push in different directions.

    Alignment

    In contrast, we can start in exactly the same situation. However, instead of pursuing the agenda of distributed autonomy, we’ll begin with an attempt to sync up everyone’s efforts.

    Low autonomy and low alignment impact on organizational momentum

    It would mean getting more arrows to point in a similar direction. I don’t expect a perfect alignment. Every individual has their own goals, which would never be matched perfectly with an organization’s goals. But we can get closer.

    The basic tool we have is the purpose. Once it’s clear to everyone what that is, two things will happen. Some people will adopt it and adjust their actions to help achieve it. It’s as if they redirected their vector more toward the desired direction.

    Others will figure that they’d rather keep pushing where they have before. For them, it would be clear they wouldn’t get much support. The odds are they’ll leave soon. If our HR does even a half-decent job, whoever comes in their place would be better aligned with the purpose.

    One way or the other, we’d get more people rowing in (roughly) the same direction.

    Low autonomy and high alignment impact on organizational momentum

    That itself changes the organizational momentum significantly. Not only did we remove the opposing force, but we also added a supporting one.

    If we follow up with increasing autonomy in this setup now, we will maximize the gains.

    High autonomy and high alignment impact on organizational momentum

    Again, everyone has bigger leverage, but thanks to synchronized efforts, the impact is so much more significant.

    Alignment First

    One could argue that we can achieve the same outcome independently of the order of changes. After all, if we refocused everyone’s efforts after increasing autonomy, the end game would look the same.

    In theory, yes. In practice, achieving alignment in such a manner is much less likely and more difficult.

    Each vector is a representation of somebody’s drive. The stronger it is, the harder it is to redirect it significantly. Think of the arrows as if they had weight proportional to the force they represent. With bigger weights, it simply requires more effort to align the vectors.

    Realignment cost with high and low autonomy

    In some cases, alignment will be impossible altogether. We extend our individual expectations to the whole organization. It’s like saying, “I want to pursue this agenda, and thus, I want my company to enable that.” While we would rarely, if ever, express it with these exact words, that’s a prevalent theme in conversations happening around job changes (exit and job interviews alike).

    Bigger arrows tend to break before we can realign them to a significantly different direction.

    Alignment versus Autonomy

    There’s a fantastic depiction of the relationship between autonomy and alignment proposed by Stephen Bungay in The Art of Action.

    He plots a two-dimensional plane with our culprits defining the axes.

    Stephen Bungay's autonomy and alignment dimensions

    In an environment with low autonomy and alignment, we won’t see much action. People will neither feel empowered, nor they would have a sense of clarity. You can expect a lot of confusion and minimal tangible outcomes.

    If we stick to low autonomy but increase alignment, we will have clarity about the goals. However, the actions will still be carefully managed and controlled. It would be a typical micromanagement environment. Not the most inspiring workplace in my book.

    On the opposite end, there’s a low-alignment, high-autonomy environment. There will be a lot going on in such an organization. The problem is that much of that effort will be misdirected. Some of it may be actively counterproductive.

    Finally, we have our most desired quadrant with high alignment and autonomy. That’s where we have clarity about the goals, and people act without waiting for permission. Their actions, thus, will be both targeted and effective.

    Interestingly enough, Stephen Bungay doesn’t stop by showing what we should expect in each type of environment. He also suggests the best path from the bottom left to the upper right corner.

    Unsurprisingly, this path leads through increasing alignment first and only then distributing more autonomy.

    Stephen Bungay's autonomy and alignment dimensions

    I can personally attest it’s a good way, as we did the opposite at Lunar. The price we paid for neglecting alignment was steep. There was a load of interpersonal conflicts, which became a borderline tribal war, and 20% of the company left in the aftermath. Show me a leader who’d willingly drive their company there.

    Big Picture

    If there were only one big-picture suggestion, I’d couple with my strong encouragement to make distributed autonomy a central piece of organizational culture, it would be about alignment.

    Decentralizing control means everyone gets more power over a company and everything it does. That may only get us promising results if everyone rows (roughly) in a similar direction.

    We won’t get that unless we explicitly work on alignment. Or are extremely lucky.

    I tend not to rely on the latter.


    This is the second part of a short series of essays on autonomy and alignment. Published so far:

    Feel free to subscribe/follow here, on Bluesky, or LinkedIn for updates.
    I also run the Pre-Pre-Seed Substack, which is dedicated to discussing early-stage products.

  • Pivotal Role of Distributed Autonomy

    Pivotal Role of Distributed Autonomy

    I’m a massive fan of distributed autonomy. I believe that, in principle, giving people more autonomy at work is the largest organizational challenge the modern workplace faces.

    Yes, the news of the day is either remote/hybrid work or the impact of AI on everyday jobs. Reinventing the organizational structures of a 21st-century corporation doesn’t belong to a broad discourse.

    From both perspectives, however, distributed autonomy plays a pivotal role.

    Autonomy in Remote Work

    With remote work, the dependency is straightforward. Much of the work has moved from the office—where it could be physically supervised by a manager—to homes, where supervision is significantly limited.

    The manager’s control is limited to the outcomes but not the actions that lead to them. For example, I can observe whether my engineers deliver features or add code to the codebase, but I don’t see when, how, and how much time they spend on activities that lead to “new features.”

    Sure, some organizations would turn to digital tools to control employees’ activities. Guess what. It doesn’t work. Well, it does, but not the way they intend. Here’s what this kind of monitoring does to people:

    • It reduces job satisfaction.
    • It increases stress.
    • It reduces productivity.
    • It increases counterproductive work behaviors.

    One hell of a slam dunk, really.

    It’s not only the lack of control, though. It’s also the availability of help. For the vast majority of organizations, remote work creates additional communication barriers.

    My leader no longer sits at the next desk. I can’t see whether it’s a good moment to interrupt them. Sure, I can drop them a DM on Slack, but they may not answer instantly. So, whenever I face one of those micro-decisions that I might have naturally delegated to my leader in the past, I may call a shot myself. It feels more convenient.

    What has just happened here was me grabbing a little bit more authority. I might have had it all the time, but I didn’t use it because it was easier to ask the leader. Now, the path of least resistance is making decisions myself.

    Multiply that by everyone in an organization, and suddenly, we have more distributed autonomy.

    The choice is between embracing and strengthening the change or resisting it. In the latter case, well, we tax ourselves on every single front, from productivity to employees’ mental health. Not really a choice, is it?

    Autonomy and AI

    The emergence of AI creates another shift in the nature of work. We get a relatively powerful co-pilot that can help us with many tasks that would be difficult or arduous in the past.

    Back then, we might have turned to the experts for help. Or drop the task altogether if it was non-essential.

    The experts would give us a suggestion, and we’d accept it as the decision. If we abandoned the task, there would be no decision to make whatsoever.

    But now, with our AI co-pilot, we have new capabilities at our fingertips. Yet it wouldn’t make any decision for us. Again, the path of least resistance is to grab some of that power, make a call, and move on.

    As an example, it’s often a challenge to dig up a relevant source to link in my writing. I often remember a research paper or article covering a useful reference. But its topic or author’s name? Beats me.

    Googling it was always a struggle, so I either turned to a human expert friend or gave up.

    But now? LLMs are pretty decent in digging up relevant options. Still, the work of reviewing suggested sources and choosing a valuable one is on me. I now face a decision that I earlier deferred to an expert or dodged entirely.

    More autonomy again.

    Adhocracy

    The changes coming from different directions align with a broader evolution of the nature of work. Julian Birkinshaw, in his book Fast/Forward, provides a neat big picture.

    Over the past century or so, the world has evolved from the industrial, through the information, to the post-information era. Each step changes the rules of the game.

    A hundred years ago, scaling was the biggest challenge, and the effective use of resources was advantageous. Thus, bureaucracy was a winning strategy.

    In the second half of the 20th century, we saw the increasing value of information, and its accessibility and effective use gave us an edge. Thus, meritocracy was gaining ground.

    Now, information is ubiquitous. In fact, with the help of LLMs, we can easily generate as much of it as we want. The world becomes less about who knows what. It’s about who can act upon (incomplete) data in a fast and effective manner. Thus, ad-hoc action gives an advantage.

    Coexistence of bureaucracy, meritocracy, and adhocracy over time.

    Birkinshaw coins the term adhocracy to describe this new mode of operation.

    A side note: one important part of the model is that all three modes of operation coexist. However, an organization will defer to the default mode whenever it faces uncertainty. We can’t expect a bureaucratic, hierarchical behemoth to act in an adhocratic way routinely.

    The coexistence of all modes will naturally create tension. The decision can’t be made at the same time made by:

    • a manager with the most positional power
    • an expert with the best data and most expertise
    • a line professional involved in the task hands-on

    If we want to embrace adhocracy, which Birkinshaw argues is a prerequisite for organizational survival, we necessarily must move authority down the hierarchy.

    We need to distribute more autonomy. Again.

    Common Part

    It’s not a surprise. When you go through the stories of companies successfully embracing non-orthodox management models, autonomy would be one shared part of all.

    Be it a turnaround story in David Marquet’s, unsurprisingly titled, Turn the Ship Around, or Michael Abrashoff’s It’s Your Ship, pushing autonomy down the hierarchy was crucial.

    And the fact that the military context would pop up so frequently in this discussion shouldn’t be a surprise. Decentralizing control was a pivotal part of the revolution of the 19th-century Prussian army. Its victory streak forced other armies to follow suit.

    Yes, the corporate world, despite all its inspirations from the military lingo, takes its sweet time to adopt the truly important inventions. And yes, our views of the military tend to be rooted more in Hollywood movies than in the actual realities of these gargantuan organizations.

    I often mention that we’d see more distributed autonomy in late 19th-century armies of the West than in many 21st-century corporations.

    We’ll arrive at the same conclusion if we stick to management theory. Take Holacracy, Sociocracy, Teal, or whatever generates the most buzz these days. The cornerstone of each of those will be autonomy. It may go into how we design roles (Holacracy), get to the principle list (self-government in Teal), or define the decision-making process (consent in Sociocracy). But it’s always there.

    When you think of it, it’s only natural. For hundreds of thousands of years, homo sapiens lived in small tribes of hunter-gatherers that were egalitarian and had very little to no hierarchy.

    Even when our species started evolving into bigger societies, adopting a strong hierarchy wasn’t given and was only one of the possible ways of coordination.

    I’d speculate that we are genetically predisposed to autonomy.

    Reinventing Autonomy

    Wherever we look, we seem to be reinventing the role of distributed autonomy. It’s critical to succeed on a battlefield. Staying relevant in business increasingly requires its presence. It sneaks along with the changes in the nature of work. We know it’s a prerequisite for engagement and motivation.

    Nothing should be easier than embracing the change and giving people more power.

    Sadly, it’s not the case. Power is a privilege. And as with every privilege, those in power will not give up easily. The good old bureaucracy will fight back.

    More importantly still, even if we have the means to overcome the resistance, the challenge is not as easy as “Let’s just give people more autonomy.”

    We need to take care of other things before we embark on this journey. But that’s the topic for another post.


    This is the first part of the short series of essays on autonomy and alignment. The following part(s) will be published on the blog and linked here during the next weeks.

    Feel free to subscribe/follow here, on Bluesky, or LinkedIn for updates.
    I also run the Pre-Pre-Seed Substack, which is dedicated to discussing early-stage products.

  • Reinvent Your Daily Meetings

    Reinvent Your Daily Meetings

    Are you still doing daily meetings in the format suggested by Scrum? The three famous questions:

    1. What did you do yesterday?
    2. What are you going to do today?
    3. Are there any obstacles?

    Do yourself a favor and stop.

    It might have been a useful practice two decades ago. But it is not anymore. Not in that form.

    The Old Cure

    Here’s the thing. The ideas behind Scrum date as far back as the 80s, and its first applications happened in the 90s. Yes, it’s that old. But that itself doesn’t deserve criticism.

    However, when you look at the 2000s, when Scrum got its prominence, your average team’s tooling looked very different. The visual boards were yet to become popular. The state-of-the-art task management system was a filtered list.

    Jira dashboard from the 2000s

    No one in the IT industry seriously talked about limiting WIP then, so we were drowned in an excessive amount of ongoing tasks. That made navigating long, long lists of work items even more of a maze from nightmares.

    It’s no wonder that people saying what they were doing yesterday and what they plan to do today was a refresher.

    The New Situation

    Fast forward 10 years, and teams suddenly have very readable visual boards as a standard practice. Limiting work in progress may still be a challenge, but we’ve gotten progressively better.

    Also, new visualization standards allow for better comprehension of whatever is in flight. Even Jira caught up.

    Jira visual board from the 2010s

    As long as:

    • the board is up to date
    • there’s even remotely reasonable amount of work in progress

    we can clearly see who’s doing what.

    How? Just look at the board—it’s all there; thank you very much.

    And if, by any chance, the board would suggest that a person still works on 5 different things, then it’s not the form of the daily meetings that is the main problem.

    Who Cares?

    If you still think the old form of the daily updates makes any sense, look at people’s engagement during them. There’s precisely one person who’s interested in the entirety of the updates.

    The Scrum Master.

    For the rest of the team, it’s a ritual they follow out of habit. At best, they are interested in what a couple of people working on the most related tasks are doing, and then they’re off again.

    So it’s like a theater with many actors and just one attendee (the Scrum Master).

    It’s even worse. Almost all that information is readily available on the visual board. So that one person could have gotten it without getting everyone involved.

    Not Just a Status Update

    That’s the point where people tell me that I describe a daily meeting as a glorified status update, which it wasn’t meant to be.

    Fair enough. So what is it?

    A way for a remote team to get together and gel? Fine, get together and gel. I doubt that answering who does what is the best way to do it.

    So, maybe, it’s a place where we discuss obstacles and problems. Fantastic! That’s actually the only original question that is still useful. Then, ask only that bloody question and be done with it.

    Whatever the purpose of the meeting is, name it. I bet there’s a better format to address that very purpose.

    And yet, in 2025, people will still answer those three questions invented three decades ago.

    Daily Around the Board

    The intention behind the original standup format was a team sync-up. That goal is still worth pursuing. However, we have options that weren’t available a quarter of a century ago.

    My default way of running dailies relies on four elements:

    • We use blockers extensively to show any impediments
    • We keep the visual board up to date (it’s “the single source of truth”)
    • We run dailies around the board
    • We read the board from right to left (or from most to least done) and focus purely on blockers

    That’s it. It’s enough to focus on the important stuff. The rest is business as usual and not worth mentioning.

    You can easily cut the daily meeting time by half (or more), make it more engaging, and (a bonus) use it as an encouragement to keep the board up to date.

    There’s literally no coming back.

    The Purpose

    Sadly, we still stick to practices. They might have been visionary decades back, but somehow, we stopped asking about their purpose and blindly stuck to them.

    If we did, we would challenge many of the techniques we use.

    Ask yourself this question: If Agile were invented today, what practices would it devise? It would most definitely be different from what you’d find in a Scrum Guide.

    So do yourself a favor, stop answering the three standup questions, and, for a change, start using this daily hangout to make something useful.

    That’s what Agile intended us to do, after all.

  • Wholeness Is a Lie

    Wholeness Is a Lie

    Over the past decade, the idea of wholeness—to bring the whole self to work—got quite some traction. The sources are many. It rides on the wave of increasing acceptance of individualism. It appears to align with diversity, which has become a major topic across HR departments.

    Last but not least, it’s one of the pillars of Teal Organizations. Teal might be far from a household name that Fredrick Laloux, who coined the term, envisioned a dozen years back. However, it successfully grabbed the wider attention of many forward-looking companies (for better or worse).

    Why Wholeness?

    Laloux’s argument for wholeness is straightforward. He juxtaposes the old-school bringing our professional, ego-driven, masculine, rational selves to work with getting access to emotional, intuitive, and even spiritual resources. The latter, he argues, is not a simple upgrade. It’s a whole different game.

    This is not mathematical, but it is only 1/16 (of us) that’s showing up. When that is the case, we also show up with 1/16 of our energy, of our passion, of our creativity.

    Frederic Laloux

    One could easily envision the yields we’d gain if only we could access 10x as much creativity pool as we can now.

    Then, for many of us, it’s only a humanistic reaction. We might think of ourselves as tolerant, welcoming, inclusive people (I know I do), and accepting others’ whole selves seems like a natural consequence of that view.

    I didn’t need much more convincing to get on board and push the wholeness agenda at Lunar Logic.

    Truly Whole Selves

    Fast forward several years, and I was trying to understand what went wrong. I was looking at a workplace equivalent of a tribal war.

    People hurt each other. In extreme cases, they even refused to work together as a team.

    While it didn’t happen out of the blue, and circumstances added a lot to the mess, none of that would have occurred without years of fostering wholeness.

    You see, no matter how we don’t like that thought, our whole selves are not all roses. We carry our dark passengers within us. We view the world around us through the lens of our biases and our prejudices. We can’t leave that dark guy at home. It doesn’t work this way.

    If we let him out, we act out. That’s when we start hurting others. The worst part, we don’t even notice.

    The Case in Point

    A few years back, environmental activists from Extinction Rebellion stopped commuter trains to London by climbing on top of them. It made the news back then, including the social media wave of comments.

    It was interesting to see how people I knew sided with either the protesters or the commuters. Interesting enough to watch the footage of the events.

    If you’ve just watched the video, you might have had more sympathy and understanding for either side of the conflict.

    Make an experiment. Pretend you know nothing about environmental activists and their agenda. Pretend you don’t understand the anger of the crowd. Rewatch the video.

    What do you see?

    See the man on top of the train trying to kick a person climbing the train in the head. Notice the crowd pulling the man down on the platform and kicking him. At its most basic level, what you see is people physically hurting others.

    These are people who bring their whole selves to the scene.

    Intentions Matter

    – But Pawel, clearly, we can’t ignore actors’ intentions before judging their actions!
    – Fine, be my guest.

    The protesters’ agenda is clear. They aim to raise awareness of the ecological crisis that humankind is engineering for itself. The commuters? They want to sustain themselves and their loved ones. For some, the delay may just be an annoyance, but for others, it may trigger serious financial consequences.

    Their intentions are clear and pure.

    I bet no one came to the platform with the intention to hurt another human being physically. Not a single person.

    And yet, here we are. We want it or not, wholeness includes our dark passengers. What follows is that, when unbounded, it brings harm. Probably, more harm than good.

    Bounded Wholeness

    So, what was the grand finale of our tribal war? We lost 20% of the people who mentioned the situation as the primary trigger for their decisions to move on.

    We found an expert to help us organize rules and norms around non-discrimination and inclusion. A big part was learning what is and is not safe for work.

    It seems a hell lot of things are not safe for work. In other words, if we want to be inclusive and non-discriminatory, we must limit ourselves.

    It’s anything but wholeness.

    Well, you could call it bounded wholeness. However, it’s akin to bounded freedom, which essentially is not true freedom.

    – But Pawel, freedom is limited, too. You can’t do anything. Your freedom ends when you start violating someone else’s freedom.
    – Sure, the lines are blurry at best. But if you want to avoid people hurting others, they need to constrain their wholeness a lot. And I mean, a lot.

    Respect as Guidance

    Before the whole thing happened at Lunar, I believed it would be enough to follow a simple rule of thumb. Something that would tell us to respect one another.

    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.

    Ray Dalio

    Or, as my favorite conference puts it in their code of conduct: “Don’t be a jerk, be excellent to each other.”

    The harsh lesson, though, is that it leaves too much space for interpretation. The closer we are to someone, the easier it is to empathize with them. As a result, the generic guidance will work for folks within our ingroup but not necessarily for those outside of it.

    The more different the outgroup from my circle, the harder it is to give them “more consideration” than I expect for myself. It’s even worse when we consider groups polarized against each other. Think modern politics.

    Suddenly, almost everything may theoretically offend someone.

    Clear Boundaries

    That’s why we need very clear boundaries. When my behavior is within those boundaries, I shall feel safe. Even if someone feels hurt, I am free to ignore it, and the other person has to get over it.

    However, when I violate the boundaries, the opposite is true. The other person has every right to expect me to stop doing whatever I’m doing, no matter whether or not I think it should be OK.

    As a team or an organization, we can negotiate these boundaries. We can bring them as far as we collectively agree upon. However, with a diverse team, we will necessarily constrain acceptable behaviors quite heavily.

    It’s not ideal. We still agree that some more sensitive individuals may feel hurt every now and then. That’s the price we pay for “unfreezing” everyone else.

    Otherwise, we’d be petrified that something we do may hypothetically harm somebody.

    Conclusion

    Wholeness, sold to us as “let’s freely bring more of ourselves to a professional context,” is a lie. As appealing as it sounds, it overlooks a critical part. While focusing on the upside, it entirely ignores the risks.

    I know it’s a hard pill to swallow, but in this case, the potential downside is more significant than the gains we get.

    If we reverse engineer the whole process and start with building a (relatively) safe work environment, we won’t end up with wholeness. At least not the kind we were sold in the first place.

    If I’ve succeeded in getting you interested, here’s a video that covers the topic in more depth. A fair warning, though. There might be triggering content inside.

  • Is Growth Necessary for Survival?

    Is Growth Necessary for Survival?

    I shared one of those quick thoughts on Bluesky as a knee-jerk reaction to yet another message encouraging startups to get on a fast-growth path.

    As luck would have it, Matt Barcomb challenged me on that remark. It turned into an exchange, where we quickly started uncovering deeper layers of strategy and portfolio decisions.

    Survival versus Growth

    The starting point is a basic observation that there are situations where survival and growth are aligned, even dependent on each other. However, there are also cases where this assertion doesn’t hold, up to a point where growth is harmful.

    As a metaphor, no species in nature grows infinitely. While a tree sapling’s survival may depend on its growth, making the process indefinite would compromise the tree’s resilience.

    Organizations work similarly, even if Bezoses and Musks of this world would deny it. That is, as long as we are willing to consider standard rules of the business game.

    There’s obviously the too big to fail phenomenon, which we’ve seen in action many times. However, it applies only to very few companies, and even when it applies, the subjects of the theory don’t end up any healthier at the end of treatment.

    For the rest of us, we may accept that growth and survivability are not always aligned.

    What follows is that when forced to choose, we should select survival over growth. If we live to see another day, we can return to growing tomorrow. The opposite doesn’t work nearly as well.

    Long-term versus Short-term

    However, as Matt points out, prioritizing survivability may lead us toward short-termism. We may always play it safe, and as a result, miss potential opportunities for big wins.

    Missing big opportunities may, in turn, be as well an existential threat, except it would develop in the long term. Consider the infamous Kodak digital photography fiasco as a perfect example.

    By the way, that example showcases that survivability is as much a short-term concern as a long-term one.

    Still, I understand that the “focus on survival first” mantra likely biases us toward what’s immediately visible in front of us. So, let’s explicitly consider survivability and time horizon as two separate dimensions.

    Opportunistic Thriving

    We can consider any combination of low or high survivability with either short-term or long-term focus.

    Any strategy threatening the company’s existence and falling into a short time frame would be suicidal (bottom left of the diagram). No sane organization would consciously venture into this territory.

    We may want, however, to stick with potentially dangerous plans with a long-term focus. This would be true when a risky move also has a huge potential upside (upper left part of the diagram). In this case, the scale of the possible gain would justify our risk-accepting strategy.

    That’s the latter part of the “sure things and wild swings” approach, also known as the barbell strategy proposed by Nassim Nicholas Taleb.

    However, if we go for the wild swings, we want to overcompensate them with sure things (Taleb suggests a 9:1 ratio). These safe bets consider primarily a predictable future and focus on preservation (bottom right of the diagram).

    If we combine the two, we land with something we can call opportunistic thriving (upper right of the diagram). We would mix some high-risk bets with a largely conservative strategy and exploit emerging chances for growth, new business, etc.

    At the end of the day, we align growth with survival, right?

    Hold your horses…

    Unfavorable Conditions

    We’re free to explore all options if the conditions are supportive, i.e., the company is already in a safe place and has resources to allocate freely among different options.

    But what if we had to make a choice? What if opportunistic thriving wasn’t an option? What if we had to make a trade-off between preservation and risky bets with huge potential upside?

    Such a situation would happen when we face unfavorable conditions. One classic example would be whether to retain the team when a downturn hits the company.

    Sticking with the proven team means maintaining options for the rebound once an opportunity arises. Here and now, however, we sustain the costs and, thus, incur financial losses.

    Playing the preservation scenario would mean layoffs and improving the financials in the short term. It would also trigger all the additional costs of rebuilding the team once the unfavorable condition is over.

    Sometimes, the trade-off is a point on a scale, e.g., how many people we lay off. Other times, it is binary, e.g., whether to engage in a risky endeavor.

    In either case, it would be a choice to prioritize long-termism over preservation or vice versa.

    Available Options

    If we assess that situation from a helicopter perspective, we realize that not all the options are available.

    To stick with the example of layoffs, we’d like to sustain the team and not incur losses. That would place us in the desired opportunistic thriving area.

    A simple fact that we consider what to do means it’s not an option. In other words, the part of the landscape becomes unavailable.

    We’d love to be as far into the upper-right part as possible, but that’s precisely the space that becomes inaccessible first. The greater the challenges an organization faces, the farther the unavailable area reaches.

    In other words, under unfavorable conditions, we’re forced to make these difficult trade-offs.

    Decision Portfolio

    But wait! While any single decision may force us to choose, the whole portfolio of decisions provides an opportunity for a diverse distribution. That way, we can hedge our risks and, through that, push the “unavailability line” back.

    That’s what the barbell strategy is all about. We actively distribute our investments across the landscape. It’s like Moneyball applied to business decisions.

    Whenever you can’t get one ideal bet (hire a star, in Moneyball terms), make a few non-ideal ones that, when combined, would deliver a comparable result (hire a few role-players with the right skills/stats, in Moneyball terms).

    Center of Gravity

    All the decisions (or bets) create a center of gravity. Interestingly, it won’t necessarily be a simple output of the weight of the bets (the size of the dots in the diagram) and their relative position.

    More forces are in play here.

    The right combination of investments may push the center of gravity in the desired direction (up and to the right). Again, in Moneyball terms, it’s like winning having a team of underdogs.

    From an organization’s perspective, what interests us most is how any decision in our portfolio affects the center of gravity. That one risky project with low chances of succeeding may be just what we need to improve our long-term relevance. Even if that swing is really wild.

    Cost of Too Many Commitments

    A brute force tactic of having a diverse enough decision portfolio may be considered. That, however, would create a whole different set of problems.

    In the past, I wrote about how too many projects at the portfolio level is a major issue for any organization. I considered how portfolio decisions are, in fact, commitments. I analyzed how overcommitment affects the Cost of Delay and can ruin the bottom line.

    It all boils down to the same conclusion: too many commitments are detrimental to (organizational) health.

    To visualize it in the landscape we created, we need to add a pulling force. It will move the center of gravity toward the bottom left corner of the diagram. Yes, straight down to our Death Valley.

    The strength of this pulling force will be proportional to the scale of overcommitment. And the relationship between the two will be exponential.

    The more bets we make, the lower the chances we’ll be able to deliver on any. Once we are already overloaded, adding more commitments will make the situation increasingly perilous.

    So, the balance we aim to strike is to have sufficient diversity in our decisions and, simultaneously, to have as few commitments as possible.

    The Startup’s Challenge

    The entire discussion with Matt began with my remark on the startup ecosystem, pushing aspiring entrepreneurs to grow at all costs.

    While the reasoning stands true for startups—especially early-stage startups—two observations make the consideration more challenging for them.

    First, by definition, they start under unfavorable conditions. And they stay so for a better part of their lifecycle. As a result, the simple shot for opportunistic thriving is unavailable for them from the outset.

    Second, the degree to which the conditions are unfavorable for early-stage startups is far greater than what established companies face. There’s no core business to rely on just yet. The runway is typically short as the availability of funding remains limited.

    The environment is challenging enough that the diversity of the bets portfolio must be compromised. And that’s precisely where my original thought falls into place.

    Fledgling enterprises, way more than established businesses, will be forced to choose between preservation and wild swings exclusively. The latter is typically characterized by a strong push for rapid growth.

    If that’s the choice, I’d go for survival. After all, dead companies don’t really grow.

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

  • Respect (and How It Makes or Breaks Culture)

    Respect (and How It Makes or Breaks Culture)

    It seems my Milk Kanban article has made a stir. I kinda expected some backlash along the “it’s not really Kanban” lines. However, when the post hit Hacker News, I got a swath of remarks attacking it from a different angle.

    The problem is, as the comments go, that someone’s job is outsourced to random colleagues. In this case, it would be Kasia (our office manager) outsourcing her job (ensuring that the office is supplied with milk) to macchiato drinkers who can’t be bothered because they have more important stuff to do.

    Oh boy, where do I start?

    Get Out of Your Cave

    It took me quite a while to grasp that some commenters perceived managing the milk supply as a priority job for an office manager.

    Yes, I know our context so much better; we’re a small company, and everyone wears multiple hats. But even in big organizations, I’d be shocked if such a matter was anyone’s top priority.

    For Kasia, it’s like the 100th thing on the list of stuff she takes care of.

    But again, even if we consider a generic example, it would be so easy to figure out how many things, big and small, an office manager takes care of. Then, there’s probably twice as much of stuff that’s not visible on the surface.

    I mean, any developer, whose primary task is working with code that’s inherently invisible, should grok that concept.

    Effectiveness versus Efficiency

    However, then things only get more interesting. Even when people considered doing something to help, they’d instantly play the efficiency card.

    “I can’t be bothered to let someone know that we’re running out of milk because I’m doing this important work, and me being a 10x developer requires absolute focus.”

    Weird that they have time for a coffee break then, but what would I know?

    But yes, having someone do 30 seconds of work, which may save someone else 10 minutes, is a sensible tradeoff. Even if the latter is paid less. Even if that half a minute wouldn’t be efficient.

    That’s the most basic effectiveness versus efficiency consideration. I can be efficient as hell, but unless we, as the whole team, can reliably deliver value, it doesn’t matter.

    It’s the equivalent of a developer whose coding pace would be fabulous, except there would be no one to code review or test their features. They may feel like they were being productive. The team, however, would be so.

    In fact, the amount of work in progress they’d introduce would make the team less efficient. It would introduce more multitasking, more rework, and more context loss.

    One has to wonder whether people showing such a lack of understanding of how the whole organization delivers value should really be valued as highly.

    A narrow focus on efficiency, especially in an isolated context, is typically detrimental to the effectiveness of the whole process.

    Respect

    However, if anything in that discussion makes me sad, it’s the lack of respect.

    “If checking the milk reserves once a day is too much of a pain for a person hired as an office manager, the person should self-reflect on his/her choice to take the job.”

    And that comes from developers, a group that is notoriously crappy at filling time tracking data, even when companies rely on that data to bill clients.

    However, my beef here is with a lack of respect for another job. Yes, this job is not paid as well. But I’m sure as hell that as much as an average office manager would fail miserably if they were to do software engineering, an average developer wouldn’t fare better in an office manager’s shoes.

    In our case, just as an example, we’re yet to have a single foreigner who wouldn’t be deeply grateful to Kasia for help with all the formal stuff related to employment papers, work permits, etc.

    In fact, it would be easier for us to lose a couple of our best engineers than to lose Kasia.

    The point is, though, that it doesn’t even matter whether we really understand someone else’s job. It matters whether we respect it as a part of the bigger whole.

    If not, it’s easy to boil it down to “I want my goddamn coffee to have milk, and someone better make sure I have it.” It’s easy to subordinate everyone else’s work only to whatever I might need of them. Then, of course, people won’t be willing to spend half a minute helping anyone with anything. Even if that someone makes sure that the milk is in the cupboard.

    I understand that in many companies, this is the norm. People are not respected, and, in turn, they don’t respect others. They won’t be willing to help with anything that’s not explicitly their assignment.

    It’s not a Milk Kanban problem. It’s a (lack of) respect problem.

    Now, establishing respect as a part of organizational culture is so much harder than making the milk supply work effectively.

    Wrap Up

    I understand the specific context of these comments. The software industry made us, in a significant part, spoiled kids. It’s still easy to sustain a lucrative career by focusing only on one’s technical skills, individual tasks, and not much more.

    I’m not necessarily surprised by how the comments disregarded the work of others, the broader context, and common goals. The sentiments, though, are not unique to software developers. I see a lot of similar attitudes in management.

    And the ways of dealing with the issue will be similar. Understand others’ roles and jobs. Understand the difference between group effectiveness and individual efficiency. Most importantly, respect others and their contributions.

    Milk Kanban or not, it’s easy to get enough milk in a cupboard. Building a culture of respect, on the other hand, is damn hard.

    And it starts with the very people who have disproportional leverage on the organization. Yes, the same folks who tend to earn more and fill the most prestigious roles.

  • Milk Kanban

    Milk Kanban

    When people say Kanban, they tend to think of a specific set of practices. Whiteboards & sticky notes (both almost universally virtual). Tasks moving through columns that represent workflow. Every now and then, WIP limits even.

    As often as we do it with other things, it reduces a broader principle to a set of oversimplified techniques, which, in turn, tend to underdeliver in many contexts.

    Kanban

    In its original meaning, Kanban represented a visual signal. The thing that communicated, well, something. It might have been a need, option, availability, capacity, request, etc.

    In our Kanban systems, the actual Kanban is a sticky note.

    It represents work, and given its closest environment (board, columns, other stickies, visual decorators), it communicates what needs, or needs not, to be done.

    If it’s yellow, it’s a regular feature. If there’s a blocker on it, it requests focus. If there’s a long queue of neighbors, it suggests flow inefficiency. If it’s a column named “ready for…” it communicates available work and/or handoff.

    A visual signal all the way.

    Visual Signals

    Let’s decouple ourselves from the most standard Kanban board design. Let’s forget columns, sticky notes, and all that jazz.

    Enters Kasia, our office manager at Lunar. One of the many things Kasia takes care of is making sure we don’t run out of kitchen supplies. The tricky part is that when you don’t drink milk yourself, it becomes a pain to check the cupboard with milk reserves every now and then to ensure we’re stocked.

    Then, one day, I found this.

    A simple index card taped to the last milk carton in a row stating, “Bring me to Kasia.” That’s it.

    In the context, it really says that:

    • we’re running out of (specific kind of) milk
    • we want to restock soon
    • there’s enough time to make an order (we don’t drink that much of cappuccinos and macchiatos)

    But it’s just a visual signal. Kanban at its very core.

    Simplicity is the King

    What Kasia designed is a perfect Kanban system. It relies on visual signals, which are put in the context. Even better, unlike most Kanban boards I see across teams, the system is self-explanatory. Everything one needs to know is written on the index card.

    That’s, by the way, another characteristic of a good Kanban system. It should be as simple as possible (but not simpler). Our workflow representations tend to get more and more complex over time by themselves; we don’t need to make them so from the outset.

    It’s a safe assumption that, almost always, there’s a simpler visualization that would work just as well. We, process designers, often fall into the trap of overengineering our tools.

    And it’s a healthy wake-up call when someone who knows close to nothing about our fancy stuff designs a system that we would unlikely think of. One that is a perfect implementation of the original spirit, even if it doesn’t follow any of the common techniques.

    Because it’s all about principles, not practices.

    That’s what we can learn from Milk Kanban.