Pawel Brodzinski on Leadership in Technology

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

Author: Pawel Brodzinski

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

  • Lateral Skills Are Core Skills

    Lateral Skills Are Core Skills

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

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

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

    What Is Value?

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

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

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

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

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

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

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

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

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

    Making Value Exchange Work

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

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

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

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

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

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

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

    Lateral Skillsets

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

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

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

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

    Which one would you choose?

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

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

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

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

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

    Asymmetric Value Exchange

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

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

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

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

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

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

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

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

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

    Side Skills Are Core Skills

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

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

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

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

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

  • The Case for Subjective Assessment System

    The Case for Subjective Assessment System

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

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

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

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

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

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

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

    The Fallacy of Assessment

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

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

    And that’s fool’s gold.

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

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

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

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

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

    Except we intuitively dismiss his assessment as subjective.

    Thinking: Fast and Slow

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

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

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

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

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

    Obviously, it is explicitly subjective.

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

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

    No wonder so many people consider their assessment systems unfair.

    The Way Out

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

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

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

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

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

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

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

    That’s when all hell broke loose.

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

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

    The Experiment

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

    What have we learned?

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

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

    The best thing?

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

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

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

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

    Summary

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

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

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

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

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

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

    What’s not to love?

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