Pawel Brodzinski on Leadership in Technology

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

Category: software business

The Ultimate Question: What Does the Endgame Look Like?
The last couple of years have been riddled with speculations about how AI will change the world. Software development and the broader IT industry are among the most affected contexts. Things are changing. The future is uncertain.

In such a landscape, it’s easy to subscribe to any speculation, like the infamous doom and gloom Citrini prediction. Before we fall for that, though, let’s look at the historical data.

It’s Q2 2026. If the AI predictions had been correct, then:
- We have AGI. As Sam Altman predicted.
- Thus, most developers don’t code anymore. That’s Matt Garman from two years ago.
- Why would they? After all, no one learns to code these days, because “everybody is now a programmer.” Courtesy of Jensen Huang.
- If you want concrete data, since last autumn, AI writes 90% of the code. Yup, that’s Dario Amodei.
- No one drops a tear over developers, though, because we already see how AI is in the midst of wiping out half of entry-level white-collar jobs. That’s Dario Amodei, too.
Yeah, I get your skepticism. That’s not reality I see around either. Fear not, however. Software engineers will go extinct this year. This time for real, says Dario Amodei. This time, we can trust him. For sure. Probably. Maybe.

Each time such an alarmistic prediction emerges, I ask one question: If X is true, what does the endgame look like?

What Is the Endgame?

I borrowed the idea of endgame from gaming, duh! Some gaming genres are built around a character progression. However, when a player character reaches the maximum level, the original game engine ceases to work. There’s no more level to grind. No more progression to make.

Thus, the endgame content was born. These are parts of a game designed specifically for max-level characters to keep the players interested. Typically, these are increasingly challenging. This time, the goal is not progress, but mastery. It’s like a game in a game.

The endgame content responds to the question of a hypothetical newbie player: “What happens if I play this game and keep progressing with my character?”

The question is interesting because we can envision the progression and intuitively realize that it can’t last indefinitely. At some point, an external constraint would impose itself, and our linear approximation of the trend (leveling up in this case) would break.

Thus, the question: What does the endgame look like?

The Endgame Question Is More Than Relevant in Business

If we look at market trends, the dynamics are surprisingly analogous. It’s not a game, so we don’t control the trends, but they’re there, sure enough. And they can’t last indefinitely. There’s always an external constraint that will impose itself.

The market share can’t go higher than 100%. The exponential growth can’t last more than a few years. Businesses need to make a profit eventually. And so on.

Now, if we ask the right questions, we don’t need to wait for the change to happen to see how the landscape will evolve. Better yet, we might see other facets of the change. Think of it as ripple effects. Then, suddenly, the landscape is richer, and we may come to very different conclusions from those we’d make if we looked at a trend in isolation.

A good example is what’s been dubbed a SaaSpocalypse—a recent devaluation of many SaaS businesses. What some perceived as the new trend predicting the end of SaaS, I consider merely a regression to the mean.

If this trend continued, the purchase price of these “old-school” product companies would be a bargain. They have healthy financials. Some have just recorded the best year ever. Unlike some of the tech scene darlings, they’re making actual profits. Plenty of them. Fundamentally, little has changed for these companies short- and mid-term.

It’s then relatively easy to see the endgame. The trend won’t continue too far, as eventually it would mean buying a dollar for fifty cents.

The Interconnected Trends and Second-Order Consequences

The endgame question is even more interesting whenever there’s no obvious limiting condition (like “you can’t have more than 100% of market share”). A good example is how AI affects coding.

We see increasing AI use in code generation. It’s not anywhere close to 90%, sure, but no one challenges that we’re doing more of that. Also, it’s obvious that AI agents can generate tons of code. And then some. No sweat.

The trend, then, suggests that we will have more and more of AI-generated code. Let’s then draw the trend line to the future and ask: What does the endgame look like?

Given how increasingly useful AI tools are, there’s no stopping the trend. At this pace, we will soon generate more code than we can reasonably review as we go. Once we stop the just-in-time code review, we will lose comprehension of what’s at the code level in our products.

The endgame is either a lights-out codebase or a risk of being outpaced by competitors. That’s an interesting dilemma. So far, research suggests that AI models are incapable of maintaining code in the long run. Yet, the business risk coming from potential competitors is real, too.

These are second- or third-order consequences of code-generation capabilities we have thanks to AI tools. And these are precisely the considerations that any product business should take into account these days.

These are far more interesting than boasting about how much code is AI-generated. As a customer, I couldn’t care less whether you generate 30% of your code. Or 90%. Or none at all. I do care whether the product solves my problem now and whether it will be technically sustainable in a year from now.

And you don’t hear Satya Nadellas and Mark Zuckerbergs of this world discussing their concerns about the maintainability of their products.

The Dynamics of the Endgame Question

The reason why the endgame question is so powerful is that it skips the current condition and jumps directly to the future state:
- What will be new or different once this new thing becomes the norm?
- When does the trend become unsustainable?
- How do correlated trends behave?
Think of it as a model. We look at one thing and have historical data on how it has behaved so far. Now, the simplest possible thing is to extend the trend line indefinitely into the future.

Except, as we already established, things do not work like this. In no reality does OpenAI have 8 billion paying ChatGPT users. So, before we predict the future, we consider external constraints.

Once we make it explicit, it becomes obvious that a naive version of the future will not happen. Even if we assume the most optimistic scenarios, the trend line will have to change its shape.

Well, that’s different now, thank you. But we’re not done yet. The most interesting things happen at the intersection. We can ask ourselves which other trends are correlated with whatever we focus on.

Like, if there’s more of this, there should also be more of that. Or vice versa, if there’s more of this, there should be less of that. As with our example, if we generate more and more code, there will necessarily be less technical comprehension. The stronger one is, the weaker the other will become.

Since we already have a clearer picture of the landscape, it’s not that hard to predict how an inversely correlated thing will change. And to what degree. Suddenly, we are equipped to ask questions about second-order consequences.

That’s where the endgame question shines. Instead of boasting about which big tech generates more code or predicting when developers go extinct, we may consider possible futures.

Human in the Loop and Coding

To run a quick example I touched on earlier, let’s consider AI and coding. Dario Amodei is wrong about how fast his AI models will take over coding. But it’s not because of the lack of capabilities of said models. I mean that too, but he knows more about these capabilities than you or me, and maybe he has all the right to believe it’s a technical problem that’s going to be fixed eventually.

He’s wrong because he considers code generation in a surprisingly isolated sandbox. If we were to believe Amodei’s predictions, we would have to assume that human-in-the-loop will be gone from software engineering.

I mean, physically, we can keep humans there, but they will have no real role. They’d be overloaded and incapable of good judgment. In fact, it’s already happening. Speculatively, though likely, in recent wars, humans-in-the-loop had the final call with decisions about strikes. Yet, you can’t expect good judgment if someone is expected to make 80 life-or-death decisions per hour.

There might still be a human body in the loop. The judgment, though? With enough cognitive load, it’s gone.

Just compare these two predictions. The first is a naive one, and considers a thing in isolation. The second attempts to understand what would change and how if the current trends stay with us. These two look very different.

The Endgame Question for Coding

So let’s look at what answers the endgame question yields in the coding example. In the past decades, we’ve been creating a growing amount of code. And yet, code review as a practice has also been increasingly popular.

AI has introduced a foreign element to our system. Now we can easily generate as much code as we want. Increasingly, we do. That changes the current dynamics of software development trends.

But wait, so far, the “code review” trend has been all good. The practice has been growing in popularity, despite the fact that, as a whole, we were developing more code.

Hell, one way of looking at it is that all code has been reviewed, since the developer creating it was doing a sort of review as part of the creative process.

The only problem is that code review is a cognitive task that requires attention. And we have a limited pool of it. If we suddenly needed to review 10x as much code, we don’t have enough engineers to handle that.

Even if we try to keep up, which I call an “optimistic” scenario here, we eventually hit the ceiling. There’s no more available attention to pay.

A side note: we could argue that we actually raise the limit by freeing developers from writing code, so they have more time to review it. That’s fair. However, we also claim we don’t need no new developers (so we don’t train them) and lay them off (so they change industries). Effectively, we’re working the limit line in both directions. In either case, even if it goes somewhat up, we’ll cross it soon enough.

With that, we’ll create a gap between the amount of code we create and the loads we are capable of reviewing. And that gap will only keep growing. Fast.

That, in turn, is the exact reason the “optimistic” scenario will not happen. Playing a losing game is no fun. Even less so if that’s an increasingly losing game. The only sensible expectation is that we will stop playing the game altogether.

The new reality doesn’t mean stopping the reviews entirely. But we’ll need to pick our battles. And we’ll need to be increasingly picky about picking them. We’ll choose only the most critical parts of the code and maintain active knowledge of them.

Second-Order Consequences of the Coding Endgame

Things get even more interesting when we consider ripple effects. Before AI, basically, all the code was read. I mean, a human wrote it, so part of the process was looking at the thing. The “code read” curve was identical to the “code created” one.

However, as we stop writing code ourselves and expect the code review rate to nosedive, we’ll look at a completely different reality. “Code read” line will detach from “code created” and will follow “code reviewed.”

Now, that’s interesting. There is more code, but save for very few carefully chosen code bases, we neither read nor understand it. It’s as if there were islands of comprehension in a black-box ocean. That is, unless we fundamentally change something. So, are we ready to run critical systems on software we can’t comprehend? Because that’s what the endgame looks like.

And that’s but one example why the endgame question is such a neat trick. The moment we start asking it, we start seeing scenarios that go way beyond the hype. It’s not just “Claude Code is so awesome; it can do the coding for me.” It’s “Would I trust a vibe-coded e-commerce with my credit card number?” Or even “How would I feel if Visa or MasterCard ran on software no human comprehends?”

The Ultimate Question

Now, I know I rode the example of AI in coding in this post. The applicability of the endgame question is way broader, though. It literally pops up anytime someone makes a kind of bold prediction, well, about anything. You know, the type of “AI is capable of erasing half of white-collar jobs, so AI labs will get unfathomably rich,” or something along the same lines.

What does the endgame look like? Well, we make half of the knowledge workers unemployed, and who’s paying the AI bills, again?

Or take this: “AI will take over content generation as it can create 100x times as much as humans can, no sweat.” What does the endgame look like? We don’t have 100x as much attention, so the vast majority of the generated content will not be consumed at all. We may have the effect of bad money driving out good, but we won’t fundamentally have use of more content.

“Thanks to AI capabilities, we’ll see a surge of new products. Anyone will be able to run a product now.” What does the endgame look like? Again, the attention constraint (or the demography) suggests we won’t have 100x as many customers. So, if anything, we’ll just increase the failure rate. While running a startup is already unappealing, it will become even less of a winning proposition, which will actively drive people away from that path.

“AI will automate applying for jobs.” What does the endgame look like? Both sides get automated to handle an increasing load. Eventually, it’s one AI agent negotiating with another to figure out whether a human is a good fit for an organization. The system is bound to be misaligned and thus gamed. What follows is that we’ll either accept hiring candidates who are increasingly unfit for the role (but who played the game better) or reinvent the hiring system altogether.

So before we jump on another bit of “CEO said a thing” journalism, it’s worth asking: if that’s true, what does the endgame look like?

As hilarious as it would be, given the topic, this post has not been AI-generated. 웃 https://okhuman.com/wLBTwg
April 13, 2026
Flailing Around with Intent
Knowing is not enough; we must apply. Willing is not enough; we must do.

Johann Wolfgang von Goethe

Does it sometimes happen to you that you try to explain something in a detailed way to someone, and that person responds with a one-liner that nails the idea? I suck at brevity, so it happens to me a lot.

That’s one reason why I appreciate so much the opportunities to exchange ideas with smart people from lean and agile communities.

The most recent one happened thanks to Chris Matts and his LinkedIn post on agile practices. Now, I’d probably pass on yet another nitpicky argument about what’s agile and what’s not, but if it comes from Chris, you can count on good insight and an unusual vantage point.

Community of Needs

One reason that I’m always interested in Chris’ perspective is that he operates in what he describes as the Community of Needs.

Members of the Communities of Needs operate in the area of “Need” to create a meme and then work with the meme to identify fitness landscapes where it fails, and evolve them accordingly. These communities have problems that need to be solved. They take solutions developed for one context and attempt to implement them in their own context (exaption), and modify (evolve) them as appropriate.

If you dissect that, people in the Community of Needs will:
- Focus on a practical challenge at hand
- Be method/framework-agnostic
- Understand the specifics of their own context and its differences from the original context of a solution
- Seek broad inspirations
- Be crafty with makeshift solutions
The word ‘practitioner’ comes to mind, although it might be overly limiting, as the Community of Needs describes more of an attitude than an exact role one has in a setup.

One might propose ‘thinker’ as the opposite archetype. It would be someone who distills many observations to propose a new method, framework, solution, etc.

Thought Leaders

Let’s change the perspective for a moment. When we look at the most prominent figures in lean & agile (or any other, really) community, who do we see? As a vivid example, consider who authored the most popular methods.

All of them ‘thinkers’ (in Chris’ frame, members of the Community of Solutions), not ‘practitioners.’

Before someone argues that the most popular methods stem from practical experiences, let me ask this:

When was the last time the founding fathers (they’re always fathers, by the way) of agile methods actually managed a team, project, or product? It’s been decades, hasn’t it?

Yet, these are people whom we rely on to invent things. To tell us how our teams and organizations should work. We take recipes they concoct and argue about their purity when anyone questions their value.

I mean, seriously, people are ready to argue that the Scrum guide doesn’t call daily meetings ‘standups,’ as if the name mattered to how dysfunctional so many of these meetings are.

It seems the price to pay for such thought leadership is following rigidity, preceptiveness, and zealotry. Thank you, I’ll pass. It feels better to stay on the sidelines. I will still take all the inspiration I want when I consider it appropriate, but that’s it. It’s not going to become a hammer that makes me perceive every case as a nail.

Where Theory Meets Practice

I admit that I have a very utilitarian approach to all sorts of methods and frameworks. If there’s a general guideline I follow, it’s something like that:

Try things. Keep the ones that work. Drop those that don’t.

Put differently, I just flail around with an intent to do more good than harm.

Over the years, I’ve learned that a by-the-book approach is never an optimal solution. Sure, occasionally, we may consider it an acceptable trade-off. In my book, though, “an acceptable trade-off” doesn’t equal “an optimal choice.”

Almost universally, a better option would be something adjusted to the context. A theory, a set of principles, a method, a framework—each may serve as a great starting point. Yet my local idiosyncrasies matter. They matter a hell lot.

A smart change agent will take these local specifics into account when choosing the starting point, not only when adjusting the methods.

For one of the organizations I worked at, Scrum was not a good starting point. Why? Were their processes so unusual that they wouldn’t broadly fit into the most popular agile method? Or maybe a decision maker was someone from another method camp? Might they be subject to heavy compliance regulations that forced them into a more rigid way of working?

Neither. It’s simply that they had tried Scrum in the past, and they got burned (primarily because they chose poor consultants). The burn was so bad that anything related to Scrum as a label was a no-go. Working on the same principles but under a different banner simply triggered way less resistance.

Local idiosyncrasies all the way. Without understanding a local context, it’s impossible to tell which method might be most useful and how best to approach it.

Portfolio Story

When we operate within the Community of Needs, even when we don’t have a strong signal like the one above, we rarely have a single ready answer.

Consider this example. As a manager responsible for project delivery across the entire project portfolio, I was asked to overcommit. And not just by a bit. While already operating close to our capacity, top leadership expected me to commit to the biggest project in the organization’s history under an already unrealistic deadline.

By the way, show me a method that provides an explicit recipe for dealing with such a challenge.

At its core, it wasn’t even a method problem. It was a people problem. It was about getting through the “but you have to make it work and I don’t care how; it’s your job we pay you for” and starting the conversation about the actual options we had. You might consider it almost a psychological challenge.

My goal was not to educate the organization on portfolio management, but to fix a very tangible issue in (hopefully) a timely manner.

If I had been a Certified Expert of an Agile Method™, I might have known the answer in an instant. Let’s do a beautiful Release Train here, as my handbook tells me so. I bet I’d have a neat Agile Trainwreck™ story to tell.

In the Community of Needs, we acknowledge that we don’t have THE answer and assess options. In this case, I could try Chris Matts’ Capacity Planning, which emerged in an analogous context. I might consider one of Portfolio Kanban visualizations, hoping to refocus the conversation to utilization. Exploiting Johanna Rothman’s rolling wave commitments might help to unravel the actual priorities. Inspiration from Annie Duke’s bets metaphor could be tremendously helpful, too.

Or do a bit of everything and more. Frankly, I couldn’t care less whether I would do that by the book, even if there were a book.

Ultimately, I wasn’t trying to implement a method. I was trying to address a need.

Flailing Around with Intent

It all does sound iffy, doesn’t it?

“You can’t know the answer.”
“You should know all these different things and combine them on the fly.” “Try things until something works.”

Weren’t the methods invented for the sole purpose of telling us how to address such situations?

They might have been. Kinda. The thing is, they respond only to a specific set of contexts. Or rather, they were designed only with particular contexts in mind, and they fit these circumstances well. Everything else? We’re better off treating them as an inspiration, not an instruction.

We’re better off trying stuff, sticking with what works, getting rid of what doesn’t.

As Chris put it:

“Flailing around with intent is the best we can do most of the time when we are trail blazing beyond the edge of the map.”

Chris Matts

So, if you want a neat two-liner to sum up this essay, I won’t come up with anything remotely as good as this one.

The Edges of the Map

We could, of course, discuss the edges of the map. The popularity of a method may suggest its broad applicability. Take Scrum as an example. Since many teams are using Scrum, it must be useful for them, right?

On a very shallow level, sure! Probably. Maybe. However, if something claims to be good at everything, it’s probably good at nothing.

The Scrum Curse

The more ground any given method wants to cover, the less suited it is for any particular set of circumstances.

And if one wants to build a huge certification machine behind a method, it necessarily needs to aim to cover as much ground as possible.

So, what is a charted map for Scrum? Should we consider any context where the method could potentially be applied? If so, the map is huge.

However, if we choose the Community of Needs vantage point, and we seek the most suitable solution for a specific need we face, then the map shrinks rapidly. It will be a rare occurrence indeed when we choose Scrum as the optimal way given the circumstances.

Then, we’re trailblazing beyond the edges of the map more often than we’d think. And flailing around with intent turns into a surprisingly effective tool.

Thank you, Chris Matts and Yves Hanoulle, for the discussion that has influenced this article. I always appreciate your perspectives.
July 3, 2025
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.

April 17, 2025
Lack of Autonomy: The Plague of the Modern Workplace

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

September 17, 2018
Teal is the New Black

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

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

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

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

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

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

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

Teal is the new black.

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

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

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

Because Teal is the new black.

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

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

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

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

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

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

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

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

September 5, 2018
Empathy and Respect: What Makes Teams Great

I’ve been known to bring up research on collective intelligence in many situations, e.g. here, here, or here. In my personal case, the research findings heavily influenced my perception of how to build teams and design organizations. The crucial lesson was that social perceptiveness and having everyone being heard in discussions were key to achieve high collective intelligence. This, in turn, translates to high effectiveness of a team in pretty much any flavor of knowledge work.

Since the original work was published, the research has been repeated and findings were confirmed. Nevertheless, in software industry we tend to think we are special (even though we are not) and thus I often hear an argument that trading technical skills for social perceptiveness is not worth it. The reasoning is that technical skills easily translate to better effectiveness in what is our bread and butter—building software. At the same time fuzzy things, like e.g. empathy, do not.

The research, indeed, was run on people from all walks of life. At the same time every niche has some specific prerequisites that enable any productivity. I don’t deny that there is specific set of technical skills that is required to get someone contributing to work a team tires to accomplish. That’s likely true in an industry and software development is no different.

As a matter of fact, enough fluency with engineering is something we validate first when we hire at Lunar Logic. The way we define it, though, is “good enough”. We want to make sure that a new team member won’t hamper a team they join. Beyond that, we don’t care too much. It resonates with a simple realization that it is much easier to learn how to code than it is to develop empathy or social perceptiveness in general.

The whole approach is based on an assumption that findings on collective intelligence hold true in our context. Now, do they?

Google is known to be on their quest to find what’s the perfect team for years. Some time ago they shared what they learned in a few year-long research that involved 180 Google teams. It seems they confirmed pretty much everything that has been in the original Anita Woolley’s team work.

It’s not the technical excellence that lands teams in the group of accomplishers. By the way, neither is management style—it was orthogonal to how well teams were doing. The patterns that were vividly seen were caring about other team members and equal access to discussion time.

What’s more, the teams which did well against one goal seemed to do well against other goals as well. Conversely, teams that were below average seemed to be so in a consistent manner. The secret sauce seemed to work fairly universally against different challenges.

What a surprise! After all, we are not as special as we tend to think we are.

I could leave it here, as one of those “You see? I was right all that time!” kind of posts. There is more to learn from the Google story, though. Aspects that are mentioned often in the research are norms, either explicit or implicit. This refers to specific behaviors that are allowed and supported and, as a result, to organizational culture.

When we are talking about teams, we talk about culture pockets as teams, especially in a big organization, may differ quite a bit one from another.

It seems that even slight changes, such as attitude in group discussions, can boost collective effectiveness significantly. If we look deeper at what drives such behaviors we’ll find two keywords.

Empathy and respect.

Empathy is the enabler of social perceptiveness. It is this magic powder that makes people see and care for others. It pays off because empathic person would likely make everyone around better. Note: I’m using a very broad definition of empathy here, as there is a whole discussion how empathy is defined and decomposed.

Then, we have respect that results in psychological safety, as people are neither embarrassed nor rejected for sharing their thoughts. This, in turn, means that everyone has equal access to ongoing conversations and they are heard. Simply put, everyone contributes. Interestingly enough, it is often perceived as a nice-to-have trait in organizations but rarely as the core capability, which every team needs to demonstrate.

Corollary to that is an observation that both respect and care for others are deep down in the iceberg model of organizational culture. It means that we can roughly sense what are capabilities of an organization when it comes to collective intelligence. It’s enough to look at the execs and most senior managers. How much are they caring for others? How respectful are they? Since the organizational culture spreads very much in a top-down manner it is a good organizational climate metric.

I would risk a bold hypothesis that, statistically speaking, successful organizations have leaders who act in respectful and empathic way. I have no proof to support the claim, and of course there’s anecdotal evidence how disrespectful Steve Jobs or Bill Gates were. That’s why I add “statistically speaking” to this hypothesis. Does anyone have a relevant research on that?

Finally, there is something that I reluctantly admit since I’m not a believer in “fake it till you make it approach”. It seems that some rules and rituals can actually drive collective intelligence up. There are techniques to take turns in discussions. On one hand it creates equal access to conversation time. On the other if fakes respect in this context. It challenges ego-driven extroverts and, eventually, may trigger emergence of true respect.

Similarly, we can learn to focus on perception of others so that we see better how they may feel. It fakes empathy but, yet again, it may trigger the right reactions and, eventually, help to develop the actual trait.

In other words we are not doomed to fail even if so far we paid attention to technical skills only and we ended up with an environment that is far too nerdy.

However, we’d be so much better off if we built our teams bearing in mind that empathy and respect for others are the most important traits for candidates. Yes, for software developers too.

September 5, 2016
Value for Money

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

June 20, 2016
Portfolio Management: Role of Autonomy

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

May 4, 2016
Value of MVP and Knowledge Discovery Process

By now Minimal Viable Product (MVP) is for me mostly a buzzword. While I’m a huge fan of the idea since I learned it from Lean Startup, these days I feel like one can label anything an MVP.

Given that Lunar Logic is a web software shop we often talk with startups that want to build their product. I think I can recall one or maybe two ideas that were really minimal in a way that they would validate a hypothesis and yet require least work to build. A normal case is when I can easily figure out a way of validating a hypothesis without building a half or even two thirds of an initial “MVP”.

With enough understanding of business environment it’s fairly easy to go even further than that, i.e. cut down even more features and still get the idea (in)validated.

A prevalent approach is still to build fairly feature-rich app that covers a bunch of typical scenarios that we think customers would expect. The problem is it means thinking in terms of features not in terms of customer’s problems.

Given that Lunar is around for quite a long time – it’s going to be the 11th birthday this year – we also have a good sample of data how successful these early products are. Note, I’m focusing here more on whether an early version of a product survived, rather than whether it was a good business idea in the first place.

Roughly 90% of apps we built are not online anymore. It doesn’t mean that all these business ideas weren’t successes. Some eventually evolved away from the original code base. Others ended up making their owners rich after they sold the product to e.g. Facebook. The reasons vary. Vast majority simply didn’t make the cut though.

From that perspective, the only purpose these products served was knowledge discovery. We learned more about business context. We learned more about real problems of customers and their willingness to pay for solving them. We learned that specific assumptions we’d had were completely wrong and others were right on spot.

In short, we acquired information.

In fact, we bought it, paying for building the app.

This is a perspective I’d like our potential clients to have whenever we’re discussing a new product. Of course we can build something that will cost 50 thousand bucks and only then release it and figure out what happens. Or maybe, we can figure out how to buy the same knowledge for much less.

There are two consequences of such approach.

One is that most likely there will be a much cheaper way to validate assumptions than building the app. The other is that we introduce one more intermediate step before deciding to build something.

The step is answering how much knowing a specific thing is worth for us. How much would we pay to know whether our business idea would work or not. This also boils down to: how much it will be worth if it plays out.

I can give you an example. When we were figuring out whether our no estimation cards make sense as a business idea we discussed the numbers. How much we may charge for a deck. What volumes we can think of. The end result of that discussion was that we figured that potential business outcomes don’t even justify turning the cards into a product on its own.

We simply abandoned the productization experiment as the cost of learning how much we could earn selling the cards was bigger that potential gain. Validating such a hypothesis wasn’t economically sensible.

By the way, eventually we ended up building the site and made our awesome cards available but with a very different hypothesis in mind.

In this case it wasn’t about defining what is a Minimal Viable Product. It was rather about figuring out how much potential new knowledge is worth and how much we’d need to invest to learn that knowledge. The economic equation didn’t work initially so we put any effort on hold till we pivoted the idea.

If we turned that into a simple puzzle it would be obvious. Imagine that I have 2 envelopes. There is a hundred dollar bill inside one and the other is empty. How much would you be willing to pay for information where is the money? Well, mathematically speaking no more than 50 dollars. That’s simple.

If only we could have such a discussion about every feature that we build in our products we would add much less waste to software. Same thing is true for products.

Next time someone mentions an MVP you may ask what hypothesis they’re going to validate with the MVP and how much validating that hypothesis is worth. Only then a discussion about the cost of building the actual thing will have enough context.

By the way the more unsure about the outcomes of validating the hypothesis they are the more valuable the actual experiment will be.

And yes, employing such attitude does mean that many of what people call MVPs wouldn’t be built at all. And yes, I just said that we commonly encourage our potential clients to send us much less work than they initially want. And yes, it does mean that we get less money building these products.

And no, I don’t think it affect the financial bottom line of the business. We end up being recommended for our Lean approach and taking care of best interest of our clients. It is a win-win.

May 22, 2015
Two Rules of Autonomy

One thing that we are doing at Lunar Logic is we evolve toward no management model of leadership. This means a lot of small changes that all happen with the same attitude at heart: to distribute more and more decision-making power across the whole company. This by the way also means systematically stripping down the management from that power.

The latter is easy in our case as the management is limited to me and I kind of launched the whole process. I would have to be either a hypocrite or a schizophrenic to resist the changes. Luckily enough I believe I’m neither. (Unless that other me has something else to say, that is.)

I don’t say it’s easy. One challenge in each step toward participatory leadership is that we, humans, don’t like to give up on power. I’m no different. I like that warm feeling that I can make a call and it shall be as I say. It’s not only that. Sometimes I simply know which option is good and the temptation to intervene and tell people what’s the best choice is strong. It would mean, however, taking a step back on a path toward democratizing leadership. So I keep my mouth shut.

On other occasions I just feel like we are going too far from my comfort zone and I slow down the process.

Giving up on power is a prerequisite to go further. While I don’t say it will go as easy in every case it isn’t enough to get that part working. In fact, despite being vocal how much I don’t want to make all sorts of decisions and how much I appreciate autonomy I still get loads of the questions that start with “Can I…”

If I’m lucky enough to suppress my System 1 reaction that would be either of: yes, yes but, no, no but answers I’d reply with “Can you?” The ball is back in your court and as long as you take responsibility for the call you make I’m OK with that.

The interesting thing is why these questions are popping up over and over again though. Despite the fact that on a conscious level we promote autonomy our natural behaviors means retreating back to the old pattern of asking for permission.

We simply don’t claim autonomy even if it slaps us in the face.

Besides years of programming our brains by education and work system that make it hard to act differently there’s another reason for that. Most of us want to be good citizens and we don’t want to use our autonomy to do stuff other wouldn’t like or even would be against. So we back up to the ultimate decision-making authority who is supposed to know what everyone in an organization likes or approves or more likely who doesn’t give a damn what anyone thinks – a manager.

The interesting thing is that the fear sometimes is well-grounded. We have different sensitivity toward different things. Behaviors that we consider positive or neutral may have negative connotation for others. If I’m a manager and I use my ultimate decision-making power and I don’t give a damn then, well, I don’t give a damn. But what if I’m just a team member who cares?

The idea we came up with is a set of two very simple rules.

1. The Nike Way
If you want to do something just do it.

2. Speak Up
If you don’t like what someone else is doing speak up.

Yes, that’s it. There’s one underlying principle, which is mutual respect. We don’t need to love each other. We need to respect our autonomy and our right to have different views on stuff.

The nice thing about this setup is that it is a self-balancing mechanism. It takes only one person try something new. It doesn’t require permission or even extensive up-front discussion. Pretty much the opposite, as a default we assume that every initiative would be awesome and everyone would love it or at least have nothing against.

The Nike Way is verbalizing the attitude described by famous Grace Hopper’s words: It’s easier to ask forgiveness than it is to get permission.

What we do know is that despite best intentions it won’t be true all the time. Occasionally, OK more often than occasionally, someone would do something that somebody else is not OK with. Then we have Speak Up rule that triggers a conscious and meaningful discussion (sometimes dubbed a shit storm) that provides additional insight for both sides and most likely some sort of consensus.

Speak Up rule was designed with a positive scenario in mind, i.e. someone unintentionally stepped on someone else’s toe. It works however in malicious cases as well. When someone intentionally crosses the line or pulls an organization in an unwanted direction someone else will speak up too.

The best part is that the same way it takes only one person to just do it, you need only one person to speak up.

One might point that there’s a risk that it would end up in indecisiveness. So far I don’t see that happening. First, speaking up doesn’t mean the ultimate veto power. It simply triggers a discussion. Second, the respect bit that is a hard prerequisite keeps the discussion civilized.

There’s a little more sophistication to balance that. Naturally extroverts would have an upper hand in unstructured discussion. That’s where empathy plays its role as helps to facilitate these weaker signals. On a basic level there are just these two simple rules: The Nike Way and Speak Up rule.

November 17, 2014