Pawel Brodzinski on Leadership in Technology

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

Tag: care

We Will Not Trust Autonomous AI Agents Anytime Soon
OpenAI and Stripe announced what they call the Agentic Commerce Protocol (ACP for short). The idea behind it is to enable AI agents to make purchases autonomously.

It’s not hard to guess that the response from smartass merchants would come almost immediately.

As much fun as we can make of those attempts to make a quick buck, the whole situation is way more interesting if we look beyond the technical and security aspects.

Shallow Perception of Autonomous AI Agents

What drew popular interest to the Stripe & OpenAI announcement was an intended outcome and its edge cases. “The AI agent will now be able to make purchases on our behalf.”
- What if it makes a bad purchase?
- How would it react to black hat players trying to trick it?
- What guardrails will we have when we deploy it?
All these questions are intriguing, but I think we can generalize them to a game of cat and mouse. Rogue players will prey on models’ deficiencies (either design flaws or naive implementations) while AI companies will patch the issues. Inevitably, the good folks will be playing the catch-up game here.

I’m not overly optimistic about the accumulated outcome of those games. So far, we haven’t yet seen a model whose guardrails haven’t been overcome in days (or hours).

However, unless one is a black hat hacker or plans to release their credit-card-wielding AI bots out in the wild soon, these concerns are only mildly interesting. That is, unless we look at it from an organizational culture point of view.

“Autonomous” Is the Clue in Autonomous AI Agents

When we see the phrase “Autonomous AI Agent,” we tend to focus on the AI part or the agent part. But the actual culprit is autonomy.

Autonomy in the context of organizational culture is a theme in my writing and teaching. I go as far as to argue that distributing autonomy throughout all organizational levels is a crucial management transformation of the 21st century.

And yet we can’t consider autonomy as a standalone concept. I often refer to a model of codependencies that we need to introduce to increase autonomy levels in an organization.

The least we need to have in place before we introduce autonomy are:
- Transparency. We can’t let people make decisions without relevant data to inform them, or decisions will be plain wrong.
- Technical excellence. Independence in acting requires the capabilities to perform these acts competently.
- Alignment. Unless we align everyone’s efforts, more autonomy only means more pull toward opposing directions.
- Explicit boundaries. We need to understand the limits within which we can act autonomously. Otherwise, we’d be both overwhelmed with possibilities and petrified by potential consequences.
- Care. Without intrinsic, genuine care about the outcomes of our decisions and actions, it’s just flailing around (and without purpose, let me add).
Remove either, and autonomy won’t deliver the outcomes you expect. Interestingly, when we consider autonomy from the vantage point of AI agents rather than organizational culture, the view is not that different.

Limitations of AI Agents

We can look at how autonomous agents would fare against our list of autonomy prerequisites.

Transparency

Transparency is a concept external to an agent, be it a team member or an AI bot. The question is about how much transparency the system around the agent can provide. In the case of AI, one part is available data, and the other part is context engineering. The latter is crucial for an AI agent to understand how to prioritize its actions.

With some prompt-engineering-fu, taking care of this part shouldn’t be much of a problem.

Technical Excellence

We overwhelmingly focus on AI’s technical excellence. The discourse is about AI capabilities, and we invest effort into improving the reliability of technical solutions. While we shouldn’t expect hallucinations and weird errors to go away entirely, we don’t strive for perfection. In the vast majority of applications, good enough is, well, enough.

Alignment

Alignment is where things become tricky. With AI, it falls to context engineering. In theory, we give an AI agent enough context of what we want and what we value, and it acts accordingly. If only.

The problem with alignment is that it relies on abstract concepts and a lot of implicit and/or tacit knowledge. When we say we want company revenues to grow twice, we implicitly understand that we don’t plan to break the law to get there.

That is, unless you’re Volkswagen. Or Wells Fargo. Or… Anyway, you get the point. We play within a broad body of knowledge of social norms, laws, and rules. No boss routinely adds “And, oh by the way, don’t break a law while you’re on it!” when they assign a task to their subordinates.

AI agents would need all those details spoon-fed to them as the context. That’s an impossible task by itself. We simply don’t consciously realize all the norms we follow. Thus, we can’t code them.

And even if we could, AI will still fail the alignment test. The models in their current state, by design, don’t have a world model. They can’t.

Alignment, in turn, is all about having a world model and a lens through which we filter it. It’s all about determining whether new situations, opportunities, and options fit the abstract desired outcome.

Thus, that’s where AI models, as they currently stand, will consistently fall short.

Explicit Boundaries

Explicit boundaries are all about AI guardrails. It will be a never-ending game of cat and mouse between people deploying their autonomous AI agents and villains trying to break bots’ safety measures and trick them into doing something stupid.

It will be both about overcoming guardrails and exploiting imprecisions in the context given to the agents. There won’t be a shortage of scam stories, but that part is at least manageable for AI vendors.

Care

If there’s an autonomy prerequisite that AI agents are truly ill-suited to, it’s care.

AI doesn’t have a concept of what care, agency, accountability, or responsibility are. Literally, it couldn’t care less whether an outcome of its actions is advantageous or not, helpful or harmful, expected or random.

If I act carelessly at work, I won’t have that job much longer. AI? Nah. Whatever. Even the famous story about the Anthropic model blackmailing an engineer to avoid being turned off is not an actual signal of the model caring for itself. These are just echoes of what people would do if they were to be “turned off”.

AI Autonomy Deficit

We can make an AI agent act autonomously. By the same token, we can tell people in an organization to do whatever the hell they want. However, if we do that in isolation, we shouldn’t expect any sensible outcome. In neither of the cases.

If we consider how far we can extend autonomy to an AI agent from a sociotechnical perspective, we don’t look at an overly rosy picture.

There are fundamental limitations in how far we can ensure an AI agent’s alignment. And we can’t make them care. As a result, we can’t expect them to act reasonably on our behalf in a broad context.

It absolutely doesn’t limit specific and narrow applications where autonomy will be limited by design. Ideally, those limitations will not be internal AI-agent guardrails but externally controlled constraints.

Think of handing an AI agent your credit card to buy office supplies, but setting a very modest limit on the card, so that the model doesn’t go rogue and buy a new printer instead of a toner cartridge.

It almost feels like handing our kids pocket money. It’s small enough that if they spend it in, well, not necessarily the wisest way, it’s still OK.

Pocket-money-level commercial AI agents don’t really sound like the revolution we’ve been promised.

Trust as Proxy Measure of Autonomy

We can consider the combination of transparency, technical excellence, alignment, explicit boundaries, and care as prerequisites for autonomy.

They are, however, equally indispensable elements of trust. We could then consider trust as our measuring stick. The more we trust any given solution, the more autonomously we’ll allow it to act.

I don’t expect people to trust commercial AI agents to great extent any time soon. It’s not because an AI agent buying groceries is an intrinsically bad idea, especially for those of us who don’t fancy that part of our lives.

It’s because we don’t necessarily trust such solutions. Issues with alignment and care explain both why this is the case and why those problems won’t go away anytime soon.

Meanwhile, do expect some hilarious stories about AI agents being tricked into doing patently stupid things, and some people losing significant money over that.
October 16, 2025
Care-Driven Development: The Art of Giving a Shit
We have plenty of more or less formalized approaches to development that have become popular:
- Test-Driven Development (TDD) focuses on writing tests before the actual code.
- Acceptance Test-Driven Development and Behavior-Driven Development are incarnations of TDD that aim to involve non-technical team members in the process.
- Domain-Driven Design focuses on connecting code with the actual business context.
- Feature-Driven Development emphasizes workflow around coding to optimize for efficient deliverability.
- Object-Oriented Development is a classic that revolves around the architectural concepts of many modern (object-oriented) programming languages.
I could go on with this list, yet you get the point. We create formalized approaches to programming to help us focus on specific aspects of the process, be it code architecture, workflow, business context, etc.

A bold idea: How about Care-Driven Development?

Craft and Care in Development

I know, it sounds off. If you look at the list above, it’s pretty much technical. It’s about objects and classes, or tests. At worst, it’s about specific work items (features) and how they respond to business needs.

But care? This fluffy thing definitely doesn’t belong. Or does it?

An assumption: there’s no such thing as perfect code without a context.

We’d require a different level of security and reliability from software that sends a man to the moon than from just another business app built for just another corporation. We’d expect a different level of quality from a prototype that tries to gauge interest in a wild-ass idea than from an app that hundreds of thousands of customers rely on every day.

If we apply dirty hacks in a mission-critical system, it means that we don’t care. We don’t care if it might break; we just want that work item off our to-do list, as it is clearly not fun.

By the same token, when we needlessly overengineer a spike because we always deliver SOLID code, no matter what, it’s just as careless. After all, we don’t care enough about the context to keep the effort (and thus, costs) low.

If you try to build a mass-market, affordable car for emerging markets, you don’t aim for the engineering level of an E-class Mercedes. It would, after all, defeat the very purpose of affordability.

Why Are We Building That?

The role of care doesn’t end with the technical considerations, though. I argued before that an absolutely pivotal concern should be: Why are we building this in the first place?

“There is nothing so useless as doing efficiently that which should not be done at all.”

Peter Drucker

It actually doesn’t matter how much engineering prowess we invest into the process if we’re building a product or feature that customers neither need nor want. It is the ultimate waste.

And, as discussions between developers clearly show, the common attitude is to consider development largely in isolation, as in: since it is in the backlog, it has to add value. There’s little to no reflection that sometimes it would have been better altogether if developers had literally done nothing instead of building stuff.

In this context, care means that, as a developer, I want to build what actually matters. Or at least what I believe may matter, as ultimately there is no way of knowing upfront which feature will work and which won’t.

After all, most of the time, validation means invalidation. There’s no way to know up front, so we are doomed to build many things that ultimately won’t work.

Role of Care in Development

So what do I suggest as this fluffy idea of Care-Driven Development?

In the shortest: Giving a shit about the outcomes of our work.

The keyword here is “outcome.” It’s not only about whether the code is built and how it is built. It’s also about how it connects with the broader context, which goes all the way down to whether it provides any value to the ultimate customers.

Yes, it means caring about understanding product ownership enough to be able to tell a value-adding outcome from a non-value-adding one.

Yes, it means caring about design and UX to know how to build a thing in a more appealing/usable/accessible way.

Yet, it means caring about how the product delivers value and what drives traction, retention, and customer satisfaction.

Yes, it means caring about the bottom-line impact for an organization we’re a part of, both in terms of costs and revenues.

No, it doesn’t mean that I expect every developer to become a fantastic Frankenstein of all possible skillsets. Most of the time, we do have specialists in all those areas around us. And all it takes to learn about the outcomes is to ask away.

With a bit of luck, they do care as well, and they’d be more than happy to share.

Admittedly, in some organizations, especially larger ones, developers are very much disconnected from the actual value delivery. Yet, the fact that it’s harder to get some answers doesn’t mean they are any less valuable. In fact, that’s where care matters even more.

The Subtle Art of Giving a Shit

Here’s one thing to consider. As a developer, why are you doing what you’re doing?

Does it even matter whether a job, which, admittedly, is damn well-paid, provides something valuable to others? Or could you be developing swaths of code that would instantly be discarded, and it wouldn’t make a difference?

If the latter is true, and you’ve made it this far, then sorry for wasting your time. Also, it’s kinda sad, but hey, every industry has its fair share of folks who treat it as just a job.

However, if the outcome (not just output) of your work matters to you, then, well, you do care.

Now, what if you optimized your work for the best possible outcome, as measured by a wide array of parameters, from customer satisfaction to the bottom-line impact on your company?

It might mean less focus on coding a task at hand, but more on understanding the whys behind it. Or spending time on gauging feedback from users instead of knowing-it-all. Definitely, some technical trade-offs will end up different. To a degree, the work will look different.

Because you would care.

Care as a Core Value

I understand that doing Care-Driven Development in isolation may be a daunting task. Not unlike trying TDD in a big ball of mud of a code base, where no other developer cares (pun intended). And yet, we try such things all the time.

Alternatively, we find organizations more aligned with our desired work approach. I agree, there’s a lot of cynicism in many software companies, but there are more than enough of those that revolve around genuine value creation.

And yes, it’s easy for me to say “giving a shit pays off” since I lead a company where care is a shared value. In fact, if I were to point to a reason why we haven’t become irrelevant in a recent downturn, care would be on top of my list.

Lunar Logic shared values

But think of it this way. If you were an aerospace industry enthusiast, would you rather work for Southwest or Ryanair? Hell, ask yourself the same question even if you couldn’t care less about aerospace.

Ultimately, both are budget airlines. One is a usual suspect when you read a management book, and they need an example of excellent customer care. The other is only half-jokingly labeled as a cargo airline. Yes, with you being the cargo.

The core difference? Care.

Sure, there is more to their respective cultures, yet, when you think about it, so many critical aspects either directly stem from or are correlated with care.

Care-Driven Development

In the spirit of simple definitions, Care-Driven Development is a way of developing software driven by an ultimate care for the outcomes.
- It encourages getting an understanding of the broad impact of developed code.
- It drives technical decisions.
- It necessarily asks for validating the outcome of development work.
It’s the art of giving a shit about how the output of our work affects others. No more, no less.
September 11, 2025
Radical Candor Is an Unreliable Feedback Model
Sharing good-quality feedback is one of those never-ending topics that we simply can’t get right, no matter how hard we try. We’d try things, exchange best practices, and… have the same discussion again, 2 years down the line.

I remember rolling my eyes at a trainer two decades back when they tried to teach us the feedback sandwich. In the early 2010s, Nonviolent Communication (NVC) was all over the place. Then there was a range of methods inspired by active listening. Finally, Radical Candor has arrived as a new take. A wave of fresh air was that it didn’t focus so much on the form, but more on what’s behind.

I wish I could refer to a single method, tell you “do this,” and call it a day. In fact, when challenged to share what is a better option, I don’t have a universal answer. Not much, at least, that goes beyond “it depends on the context.”

If there’s something that I found (almost) universally applicable, it is to share any feedback in a just-in-time manner. The shorter the feedback loop, the better.

Yet, of course, there is a caveat to that as well. Both parties need to have mental capabilities to be there. Sometimes, especially when hard things happen, we aren’t in a state when this is true, and we’d better defer a feedback session to a later point.

Also, it doesn’t say a thing about the form.

Radical Candor

Kim Scott’s Radical Candor is continuously one of the most frequent references when we discuss feedback. Its radicalness stems from the fact that it abandons being nice as a desired behavior and advises direct confrontation.

In short, as a person delivering feedback, we want to be in a place where we personally care about the other person and we challenge them directly. No beating around the bush, sweet words, or avoiding hard truths.

Caring personally is the key, as it builds this shared platform where we can exchange even harsh observations and they will be received openly. After all, the other person cares.

The other part—challenging directly—is more straightforward. We want to get the message through, leaving little space for misinterpretation, especially when feedback is critical.

Do We Personally Care?

Out of the two dimensions, the directness of a challenge is the easier one to manage. We can pre-prepare feedback so that it goes straight to where we want it to land. This way, we avoid ruinous empathy territory.

The caring part, though? How do we figure out whether we care enough that our message will be radical candor and not obnoxious aggression? How do we know that we are here and not there?

I’m tempted to say that we should know the answer instantly. After all, it’s our care. Who’s there to understand it better than ourselves? I’m teasing you, though.

Figuring it out in front of the mirror will often be difficult. More so in environments where care is not a critical part of organizational culture, and thus, does not come up easily.

Then, it’s not just about whether we care or not. It’s as much about whether we are able to show it.

A simple advice would be to show as much care as we reasonably can. We bring that dot up as much as we can, and things should be good, right? Oh, if only it were that simple.

Feedback: Radical Candor or Obnoxious Aggression

Some time ago, I was talking to one of our developers, who was complaining about another person. The other person had asked questions/challenging the developer about relatively sensitive matters.

Then, it struck me.

“OK, I remember myself making exactly the same remarks and asking exactly the same questions. Does it mean that I have offended you, too?” I asked, upon realizing that at least in one case, my behavior was a carbon copy of the other person’s.

From the response, I learned that I was OK. The other person was not. Why? “Because you care and [the other person] does not.”

In other words, I was in a safe space of radical candor, and the other person was way down in the obnoxious aggression territory. Except we were precisely in the same spot (same behaviors, same remarks).

The whole situation was all about how the said developer interpreted specific situations and how much goodwill and leeway they gave me and the other person.

Where Are the Lines?

The story clearly shows that we can’t fix the lines in place in the Radical Candor model. It’s not a simple chart with four quadrants, where we necessarily want to aim for the upper right corner.

The borders between the domains in the model will move. They will be blurry at times. And, by no means, will they be straight lines. If we tried to sketch a model for an actual person, it would look way messier.

There will be areas where we’re more open to a direct confrontation, and those that are way more sensitive.

Take me as an example. I tend to consider myself a person who’s open to critique (and I’ve done some radical experiments on myself on that account).

I’m fine if you question my skills, judgment, or the outcomes of my actions. Not that it’s easy, but I’m fine. But question my care? That’s a vulnerable place for me, and you’d better be less direct if that’s what you’re about to do.

To make things worse, the picture will be different depending on who is on the other side. For a person I deeply trust and respect, the green area will dominate the chart. For another, where neither trust nor respect is there, the green space may be just in a tiny upper right corner.

And if that wasn’t enough, it changes over time. We have better days and worse days. We have all other stuff to deal with, stress, personal issues, and all those things conspire to mess with the Radical Candor clean chart even more.

“Fuck off” Coming From a Place of Love

During my first weeks at Lunar Lugic, one of the youngest developers at the company told me, in front of a big group, that “I acted like a dick.” It was his reflex response to something I did, which I can’t even remember now. Nor can he.

The next day, he came to the office with a cardboard box to pack his things, ready to be fired for offending the newly hired CEO. Little did he know that:
- I was grateful for his timely remark
- I appreciated his courage
- I couldn’t care less about the form
Even if none of the common advice would suggest that, for me, it was indeed a quality bit of feedback. And the developer? He stayed with us for more than a decade. And he definitely didn’t need that cardboard box.

His challenge was direct and blunt. Did he care about me personally, though? No. Did it change anything for me? No, not really. For me, the remark has still landed well in the radical candor territory.

As a metaphor, I have some people in my life whom I can tell to fuck off. Or vice versa. And that “fuck off” would come from a place of love. The form, while harsh, is something that bothers neither me nor them. After the shots have been fired, we will laugh and hug.

I bet you have such people in your life, too. Those who have seen the best and the worst of you and decided to stick with you, nevertheless. People you trust and who trust you. You respect them, and they return the favor.

Send the same “fuck off” to a random colleague and you’re neck-deep in obnoxious aggression, no safety guardrails whatsoever. Although, in this case, it should instead be called obnoxious violence. No amount of personal care can fix this.

Radical Candor Is an Unreliable Feedback Frame

As a theoretical model, Radical Candor is neat. I really like a cross-section of personal care and direct challenge as a navigation tool in communication.

However, it creates an illusion of precision while pushing us more toward unfiltered, well, candor. This combination is harmful more frequently than just occasionally.

We can figure out (roughly, at least) where our message is on the diagram. The big problem is that we’re mostly clueless about where the lines are.

In fact, we have good insight into the borders between the domains only after we have established a pretty good relationship. Which is precisely when we need the least awareness about the exact line position.

In a typical case, we’d be shooting in the dark. Even if we understand the form and the content of feedback we share, it may lead us to a very different place than we expect. Many of the reasons why are beyond our sphere of control.

Feedback Instruction Manual

I’d be reluctant to adopt Radical Candor as my go-to feedback frame. However, if someone comes to me and says that’s what they expect, I’m happy to oblige.

That’s a good trick, by the way. As a person who wants to receive more feedback (don’t we all?), tell people how to do it in your case.

For example, I prefer criticism to praise. The latter sure feels good, but it does little in helping me improve. I’d rather feel awful for a while and get better afterwards than the reverse.

I appreciate challenges. Which doesn’t mean that I’m quick to admit I was wrong. I need time to rethink my position. So, if you want such an outcome, give me that time.

And I could go on. But this is my instruction manual. I don’t expect it to work for anyone else automatically.

The same is true when you are on the sharing end. Be explicit about your intentions. I routinely start or finish (or start and finish) giving feedback with the following remark:

The first rule of feedback applies: Do whatever the hell you want with it.

Save for some edge cases, I never have any explicit expectations for a change. When I share, it’s just this—sharing.

Being explicit about your intent will do way more than following any fancy model.

This post has been inspired by the conversation with Lynoure Braakman on Bluesky. Thank you, Lynoure, for the insightful remarks and the inspiration.
August 21, 2025
Care Matters, or How To Distribute Autonomy and Not Break Things in the Process
At Lunar Logic, we have no formal managers, and anyone can make any decision. This introduction is typically enough to pique people’s curiosity (or, rather, trigger their disbelief).

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

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

Transparent Salaries

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

As you may guess, not all remarks were supportive.

My favorite, though?

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

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

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

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

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

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

Cautionary Tale

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

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

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

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

The cycle has perpetuated.

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

It’s just people didn’t care.

Care

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

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

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

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

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

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

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

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

He nailed it.

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

How Do You Get People to Care?

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

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

So, how do you change such perspectives?

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

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

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

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

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

The Role of Care

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

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

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

But that wasn’t my answer.

My answer was:
- Everybody knows our P&L
- Everybody knows the invoices we issued last month
- Everybody knows the costs we have to cover this month
- Everybody knows the broader context, including people’s concessions
- We have autonomy
- Go ahead, make your decision
In the end, we’re doing a potluck-style collection.

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

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

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

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