Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
Melvin E. Conway

Why would an organizational structure of a company have anything to do with software architecture? After all, there are whole bodies of knowledge covering high- and low-level concepts of software development. Aren’t these things properly planned and executed?

I mean, sure, in the details, there will always be a mess. However, in a grand scheme of things, the high-level design should be far more controllable than the law suggests.

In retrospect, Conway’s Law is one of those things that, once you’ve seen it, you can’t unsee it.

Conway’s Law and Spotify Model

Whenever Conway’s Law emerges in a discussion, my favorite example is Spotify. I’m a user since the beta. I know several people who worked there in leadership positions. Most of all, Spotify, at some point, was very vocal about their organizational approach, the so-called Spotify Model. It’s like I have enough data to connect the dots.

As popular as it was at the time, if you look at the Spotify Model, it’s hard not to see it as a glorified matrix organization. Yes, there’s more autonomy across the board, but the communication paths? They all scream “Matrix!”

What should we expect from their product design if Conway’s Law is true? My best guess is a set of features interconnected in non-obvious ways, with a common issue of lack of alignment, and a lot of local optimizations. And that’s precisely what we get.

Spotify UX

While Spotify’s codebase is not open, its UX is quite telling. By now, it’s a clutterball of misaligned ideas fighting for your attention.

From a user perspective, it’s fascinating, although not in a good way, how I struggle to find the same options that I use regularly (like, multiple times a week, for years). Managing playlists? Oh, boy. Search? Every other time, it’s in the wrong context. Inconsistencies between mobile and web? Don’t get me started.

But maybe it’s just grumpy me. Fine. I’ve just literally googled “who loves spotify ux?” and among the top results are:

• Who at Spotify designed their interface, and why is that person clinically insane?
• Why is Spotify so popular when it’s UX is pretty bad?
• Who think Spotify App Experience (UX) sucks and why?

Doesn’t sound like a love wave, really. It’s either one: Google reads my mind, or the UX is problematic.

All that comes from a product praised (and copied) for some product innovations, such as Discovery Weekly or Spotify Wrapped. Most definitely, not everything is wrong here. It’s just a matrix of somewhat misaligned ideas, good and bad. That isn’t really a recipe for customer delight.

By the way, did you know that Spotify has a custom seek bar for Star Wars songs that looks like a lightsaber? And you can change the looks of the specific lightsabers, no less. There could hardly be a better illustration of “a matrix of somewhat misaligned ideas, good and bad.”

Communication, Alignment, Autonomy

If you consider Conway’s Law, it’s hard not to see how Spotify UX is a precise map for the Spotify Model. Wherever communication between teams (squads, guilds, chapters, or whatever the hell they call them) was messy and faced multiple conflicting goals, so did the interconnections between features.

To make things harder, Spotify sprinkled high autonomy over their feature teams. So the matrix organization made alignment a challenge, yet decision-making was pushed down the hierarchy nonetheless.

A high-autonomy-limited-alignment setup is not a recipe for effective work. And I say that from experience. At Lunar, we walked that path. The lesson? As much as I’m a huge fan of distributed autonomy, I’d always consider alignment first.

In the late 2010s, Spotify had a few dozen relatively independent feature teams responsible for specific parts of the product. Small wonder that the “mobile playlist” team had different ideas from the “web playlist” team. Communication paths that might have fixed that were watered down by an overly complex organizational model.

By now, the engineering headcount is already in the thousands, and the team count is thus in the hundreds. Just imagine the product mess that the Spotify Model would create. No wonder they largely abandoned it.

OK, but what does it have to do with AI?

AI Product Management

Product people are encouraged almost as strongly as developers to use AI extensively. It comes as a mixed blessing. Early intensive prototyping is a viable path, and it opens up whole new avenues for validating product desirability.

LLMs make it just so easy to create extensive specifications. We can attach all the existing product descriptions as context, let AI do its own research, analyze the codebase, and more. It will produce a nice, detailed description, and the engineers will nail it.

Except we misinterpret the ease of creation for the value of the output.

A sidenote: It’s the same aspiration we had when we tried to model systems with UML diagrams, and it didn’t work either. It’s not about the tools. It’s about the iterative exploratory nature of designing software.

Still, AI can create the same illusion we followed many times before—that we can specify software upfront in detail from the outset. The output looks good. Better than ever, even. And we get it effortlessly. It’s the AI model that does the heavy lifting.

It takes some time to realize that product development doesn’t work like this. It never has. And it has nothing to do with the tools we use to create specs.

AI Kills Communication

In the past, product specifications were brief. Save maybe for some Business Analysts, no one fancied writing long forms describing all the feature details. We relied on just enough context and communication between engineers and product people.

However, now, generating detailed specifications with AI is easy and cheap. Initially, we might even verify whether the output is correct. Eventually, we’ll give up. One, often they’d be good enough. Two, LLMs are great at creating outputs that sound sensible. Three, honestly, read a 4-pager with a feature description and tell me you understood everything.

At some point, and sooner rather than later, a product manager will stop carefully verifying AI output. Soon, the developers will follow. That is, given they read the extensive specs at all in the first place. It quickly evolves into the “you give me the specs, I’ll get them built, no questions asked” kind of scenario.

The key part here is: “no questions asked.” It’s like going all the way back to the 90s, way before Agile happened. We build up to the specs, whether it makes sense or not. The only difference is that we deal with the development so much faster. Does it matter, though, when we build the wrong thing?

Conway’s Law Meets AI Product Management

The most important change happened in between the lines, though. A one-sentence-long feature description was, by definition, full of holes and required the team to discuss. A detailed specification creates the illusion that a feature has been thought through from all angles.

The former invites communication. The latter discourages it.

As we close down communication paths, Conway’s Law kicks in. We’re bound to design architectures that copy organizational communication structures.

Less peer-to-peer communication and less collaborative exploration mean a more fragmented and less coherent architecture. As each individual is treated more and more as an isolated island, so will be the code that individual develops.

The effect will affect both a technical level (think code architecture) and a product level (think UX). Give such a way of working a couple of years, and we’ll start praising Spotify for its exceptional product design in comparison.  

AI Is on a Collision Course with Conway’s Law

Dev: The last feature is on staging.
PM [checks the feature out]: It doesn’t work as specified! Here’s what should be different.
Dev [checks the code, checks the specs, 2 hours have passed]: Well, actually, it works as specified. Here are the specific parts that prove my point.
PM: Oh, my Claude must have hallucinated that part.

That’s an actual conversation that I heard that inspired this article. When I consider the impact of AI on communication, the paths connecting product and engineering are most affected. Yet, similar effects emerge across the board.

• A single developer may produce more code with AI tools, so they are more independent and, even under time pressure, they don’t need to collaborate with other engineers as often. We reduce the need for communication.
• Coding agents running independently step on each other’s toes way more carelessly, creating merge conflicts and triggering rework (the worst kind of rework, actually). Operators of said agents are thus better off when they isolate their active work areas. Which means less coordination and less communication.
• The asynchronous nature of working with AI agents incentivizes the “throw over the fence” hand-offs. My agent’s output may be ready when I’m already off, but let that not stop you from doing whatever you need to do with it. Again, less human-to-human communication.
• The sheer amount of documentation we can generate on different levels automates away collaborative activities (or parts of them). Code review? Let an agent handle that. Even less communication, perchance?

If Conway’s Law holds, we may be up for a rude awakening. As an industry, we are hyped about all sorts of “my agent talks to your agent” scenarios. It’s easy to see the upside—automating away the mundane, tedious, and routine. It’s hard to see the long-term cost of deteriorating communication paths.

So, we either learn to navigate the new realities of collaboration better, or we accept that the products we use will increasingly be crap. Which one will it be?

These posts are not generated. 웃 https://okhuman.com/nf1GGg

The post Conway’s Law Teaches a Grim Lesson About AI in Product Development appeared first on Pawel Brodzinski on Leadership in Technology.

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

The post The Ultimate Question: What Does the Endgame Look Like? appeared first on Pawel Brodzinski on Leadership in Technology.

• I mix engagement and motivation, and they are not simple substitutes for one another.
• Gallup’s State of the Global Workplace has faced some criticism for not actually asking about engagement, but instead inferring it (by the way, this book explains the methodology behind the research).
• We all have anecdotal stories about limited-autonomy environments where engagement doesn’t seem to be a problem.

So how is it, really? Do we really feel more engaged when we have more control over the work we do?

I have the privilege of running the course on progressive organizations in all sorts of settings, from MBA programs, through postgraduate studies, to professional training. As a part of the course, I designed a little experiment to run with all those different crowds. Over the years and across contexts, it keeps telling the same story.

What Can LEGO Teach Us About Autonomy?

The experiment is fairly simple. I get a group of people to build a relatively simple LEGO set. Twice.

The Managed Build

The first run is well-organized. We pick one team member as a manager, who starts by assigning tasks to the rest of the team. A typical team member’s job would be to:

• Be responsible for a specific type or color of pieces.
• Build a particular part of the model.
• Etc.

Over the years, I experimented with how much freedom a group’s manager has in organizing work. It doesn’t seem to matter. What’s important here is that the whole work organization is designed by—and, to a degree, enforced by—a single person.

Then they get to build a catamaran. With instructions. Displayed on a screen. With me controlling the pace. Actually, it’s they who control the pace. I “flip” the page once the last team is ready.

Eventually, all the teams build perfect catamarans. Up to specs. There are some subtle challenges in the process, but that goes beyond the context of autonomy versus engagement.

The Self-Organized Build

The second run is different. There aren’t managers anymore. There is no task assignment pre-building. The whole instruction is: “Self-organize.”

There is no instruction either. The only thing a group gets is the picture of a hydroplane they’re building.

People have all the freedom to organize their work. Sometimes they do plan. Much more often, they don’t. A creative and messy process commences. Inevitably, it’s all louder and more chaotic than the first run. On average, it’s a bit longer, too.

Eventually, I get my hydroplanes. Some of them perfect. Others not so. However, I’m yet to receive one that differs from the picture in anything other than minor details.

The Lesson

While there are many facets to this experiment, the big lesson is about engagement. After each run, I ask everyone individually to assess their engagement during the task on a scale from 1 to 5:

1. Very low
2. Rather low
3. Neither low nor high
4. Rather high
5. Very high

The underlying hypothesis is, of course, that the second run, the one where people have more autonomy, yields better engagement.

Across all the teams that have ever participated in the exercise, the current running averages are:

• 3.24 for the managed build
• 3.94 for the self-organized build

There wasn’t a single experiment in which teams were less engaged in the second run (though in one case the results were close—0.14 difference).

In other words, I’m yet to see a group of people who would be less engaged in a creative LEGO build when they were given more autonomy.

Some Experiment Caveats

One important aspect of the experiment design is that the models are relatively simple, while I organize people in groups of 4 or 5. As a result, there are too many hands for the task. It is so by design. It’s an environment where it’s relatively easy for people to disconnect, should they choose to.

Also, it’s LEGO. For some people, it will be inherently engaging no matter what. They tend to take an active part in the first run, disregarding their assigned role.

Those two aspects of the game create an environment in which people use the full scale when assessing their engagement. I’ve only had one group that hasn’t used 1s at all. Possibly too many AFOLs in the room.

The pace of flipping the instruction pages in the managed build tends to be a minor source of frustration for faster teams. Again, that’s by design. It’s just another dimension of limited autonomy. After all, with real work, we have all sorts of interdependencies.

A side note: Interestingly, it’s not always the same team that is the slowest throughout the whole run. It’s a classic case of a shifting bottleneck.

Distributed Autonomy Is a Crucial Prerequisite for Engagement

My working hypothesis is that the main reason behind appalling engagement levels is limited autonomy. The theory suggests as much.

The LEGO experiment is a neat way to confirm that in practice. With a simple change of giving people more autonomy, the declared engagement goes up by more than 20%.

The observable behaviors are different, too. The managed build generates way less energy, fewer discussions in teams, less movement across the room. If you saw randomized silent movies (no audio) from the respective experiment runs, it would be obvious which is which.

Distributed autonomy—being able to decide how we work—is an absolutely crucial aspect of our workplaces. And a prerequisite for high motivation and engagement.

This is part of a short series of essays on autonomy and how it relates to other aspects of the modern workplace. Published so far:

• Pivotal Role of Distributed Autonomy
• Role of Alignment
• Care Matters, or How To Distribute Autonomy and Not Break Things in the Process
• Limited Autonomy Is the Main Reason for Low Engagement Levels

I’m writing these posts by hand. Like an animal.
웃https://okhuman.com/NbZHoQ

The post What LEGO Can Teach Us about Autonomy and Engagement appeared first on Pawel Brodzinski on Leadership in Technology.

After dropping in 2020 during the pandemic, employee engagement is on the rise again, reaching a record-high 23%.

Yup, it reached a record high in 2022, stayed there in 2023, and dropped again in 2024.

We had COVID-related uncertainty to blame for the drop last time. This time it’s AI-related uncertainty. Here’s a thing, though. We discuss marginal changes. A per cent here, a per cent there.

The big lesson remains the same. Engagement levels in the modern workplace are appalling.

If it were a football team (a soccer team for my American readers), it would be as if 2 players tried to win, 7 just moved around without much engagement, and 2 more tried to score an own goal. If you’d rather take a basketball metaphor, you get one baller who tries to win, 3 who fake defense, and one who keeps turning the ball over to the other team.

The only hope of actually winning is that the other team is about as disengaged as yours.

These are realities we have lived with in the past decade. Before that, it was even worse.

Autonomy, Mastery, Purpose

So why is the engagement so low? I like Dan Pink’s answer. In his classic book Drive (and no less classic TED talk: The puzzle of motivation), he points 3 prerequisites for high motivation.

• Autonomy. The ability to decide about important aspects of the work we’re doing.
• Mastery. Being able to work according to our own aspirational quality standards and get better at what we do.
• Purpose. Having a shared goal with a broader team or group, we collaborate with.

Remove either, and you remove the conditions for engagement. Since we have a motivation gap, at least one part of the trio must be the culprit.

Purpose tends to be relatively individual for companies. You can probably instantly think of organizations that are purposeless (take any that have “increasing value for shareholders” painted all over the place) as well as those that are purposeful.

Mastery is trickier. However, in the context of knowledge work, I see a one-way correlation between autonomy and mastery. If you can make all relevant decisions about how you work, you very likely can work according to the aspirational standards you set for yourself. If you have autonomy, you can have mastery, too. The vice versa is not necessarily true.

So yes, when I have to explain Gallup’s results, I blame autonomy, or rather, lack thereof.

Hierarchy Discourages Autonomy Distribution

In a modern corporation, we perceive hierarchy as the only possible organizational paradigm. Hierarchy here is understood as a decision-making power distribution structure. The higher up you are in a hierarchy, the more (and more important) decisions you can make.

Sadly, that very structure discourages us from distributing autonomy to lower levels. If I hypothetically allowed my team to make the decisions assigned to me, inevitably, I’ll face a situation where someone makes a decision I disagree with. Then I face two choices, both bad.

I can stick with the decision that goes against my experience, intuition, and better judgment. However, since it was mine to make, I’ll be responsible for its outcomes. If my experience, intuition, and judgment were any good, I would pay the consequences of a mistake, even though I knew it was a wrong call in the first place. Psychologically, it’s a tall order.

The other option is to change the decision. In one swift move, I fix the decision and show my team that they didn’t have any autonomy in the first place. They could “make” decisions only as long as these were decisions I would have made anyway. If that sounds like a kick in the teeth, it’s because it is.

Hierarchy discourages managers from distributing autonomy. Add to that how prevalent this organizational model is, and we have an answer to why engagement in the modern workplace sucks big time.

The Writing Is On the Wall

No matter which vantage point we choose, we see the same picture.

• We cheer appalling engagement levels only because they’re slightly better than they were.
• We listen to Dan Pink’s rants with awe, then go back to the same old solutions that never worked.
• We applaud stories of bold leaders who challenged the status quo with stunning results, and rationalize them, saying, “It would have never worked in my company.”

I’m curious, how well your current “solutions” work? If we believe Gallup data, there isn’t much to brag about. On the one side, we have unquestioned dogma, which we have followed for more than a century. On the other, we have science. In such cases, I tend to pick team science.

This is Dan Pink again:

“This is one of the most robust findings in social science, and also one of the most ignored.”

“There is a mismatch between what science knows and what business does.”

The writing is all over the wall. And it will only get more pronounced as we surrender parts of our autonomy to AI agents. Let’s not expect fundamental changes in our motivation levels.

Unless we start treating the autonomy gap seriously, that is.

This is part of a short series of essays on autonomy and how it relates to other aspects of the modern workplace. Published so far:

• Pivotal Role of Distributed Autonomy
• Role of Alignment
• Care Matters, or How To Distribute Autonomy and Not Break Things in the Process
• What LEGO Can Teach Us about Autonomy and Engagement

This post has been human-created: 웃https://okhuman.com/g8lX5w

The post Limited Autonomy Is the Main Reason for Low Engagement Levels appeared first on Pawel Brodzinski on Leadership in Technology.

Here’s a sad reality for many people applying for a job:

• Their competitors (i.e., other candidates) use AI tools to mass apply.
• As a result, hiring companies are flooded with applications, and sifting through all of them is impractical.
• What follows is that hiring companies defer to other AI tools to filter out the vast majority of applications (often as much as 95%+).
• The recruitment game becomes one of prompting one AI agent to pass through the filters of another AI agent.

Realities of Job Seekers A.D. 2025

Imagine that there is a job that you really want to get. It doesn’t even matter why. It may be because you know that the company is great, or the job profile matches your dreams perfectly, or you perceive the experience you’d get there as unique, or whatever. You just want in.

But hey, since all those other people are using AI tools to spam the hiring company’s application form, your submission will disappear in that flood.

It’s even worse than that. If you hand-craft your application to show your genuine care for the job, it’s almost certain that you’ll be rejected. After all, your original story will be written to a hiring manager (a human), but it’s never going to get there in the first place. It will be rejected by an automated AI tool (a bot) precisely because it’s non-conformist.

Such a resume doesn’t match the most common patterns. There aren’t many similar examples in the AI model’s training data. It’s not common enough.

If you want your application to get past the AI filter, you kinda have to play the game everyone else does. Optimize for what a bot wants. And it’s impractical to do it by hand. Just hire another AI agent to do it for you.

Except that you’ve defeated the purpose that way. First, you aren’t more likely to get through. Second, even in the case that you do, the hiring manager will see another similar, bland-but-professional resume. You will not stand out.

Most importantly, you will not carry over your care about that job.

Recruitment in the AI Era Is Irrevocably Broken

The story above neatly pictures how broken the recruitment has become. What’s more, there’s no going back.

You can pretend it’s 2020 and send your manually-crafted CV, but you’re going to lose to people auto-submitting thousands of AI-generated resumes. Oh, and said resumes will be automatically tweaked to better match a job description, with no human effort whatsoever.

A resume doesn’t work as a token of information exchanged between two humans (a hiring manager and a candidate) anymore.

The career of a resume is over. At least the one that we know. If anything, a CV becomes a token exchanged between two AI agents, neither of which is programmed by the actual candidate.

No matter how hard we try, there’s no coming back. We can’t make resumes unbroken again. Even if we aspirationally tried to restore the original meaning of a CV, there will always be a rogue player who will exploit that trust by mass-applying with generated stuff. And since that will give them a short-term advantage, others will follow suit.

Winning the Game by Not Playing It Altogether

It’s ironic how both sides of this equation—recruiters and candidates alike—are losing in the new setup. Candidates have it harder to show their care about specific jobs. Companies give up on the best matches because they employ a bot to reject 95% of applicants. And yet, no one can change the rules anymore.

So, is conforming to the new state of things the only option?

In the classic movie WarGames, the AI, which is trying to “win” the nuclear war, eventually learns that it always ends in mutual assured destruction. The only winning move, thus, is not to play at all.

It’s the same with recruitment. If the current system forces us to mass-produce thousands and thousands of resumes that no one will ever read, we’re just adding noise to the system. The winning move? Not to play.

But wait, if you want to change jobs, how are you supposed not to play the game? If you never apply, you never get that dream job of yours. Or a better one than you have now.

Trust Networks as Antidote to AI Slop

In recruitment, as much as in any other area, we will defer to trust networks to circumvent the noise. The more toxic AI slop is in the feed, the less we trust the feed altogether, and the more we rely on human-to-human connections.

One side of relying on trust networks is that companies increasingly go for employee referrals rather than traditional open recruitment processes. That doesn’t solve the other part of the equation, though. What if I am a candidate and want that specific job?

Do the same. Build a connection with someone at that company. We live in an interconnected world, and there are still places where a genuine message will stand out. They may attend local meetups, be active on LinkedIn, maybe publish a blog or a Substack, or engage in some other professional activities. If you care, you will figure that out. Get to know people first, and only then apply.

Does it seem like a lot of effort? That’s precisely the point. It shows how much you care.

Very recently, we made our first hire in almost two years. We didn’t even open a recruitment process. There was this guy who stayed in contact after we talked a few years back. And then, eventually, it was a good time for him and a good time for us. A win-win.

The point is: he made the effort to reconnect. He made it easy for us to remember.

This could only happen because we’ve built the human connection beforehand. We were two parts of the same trust network.

Would You Pay To Put Your Resume at a Hiring Manager’s Desk?

I admit, relying on trust networks is a lot of effort. And it takes time. Both would make the approach impractical at times. So what if there were a shortcut?

That brings me back to my original question. As a candidate applying for a job, would you pay to skip the AI line? Would you pay to ensure that your application is read by a human?

Note, your resume would still go through regular scrutiny. It’s just you’d know a human would do it, not a black-box AI agent.

There’s an interesting balance here. Make it too cheap, say $0.02, and it changes nothing. People would still be mass-applying all the same, so no one would take that seriously. Make it too expensive, say $200, and it’s probably not a good return on investment for a candidate. After all, no one would hire such a candidate or even rate them any better. A hiring manager would just read and assess the resume as if it passed the AI filters.

What’s in it for a candidate? It’s an open avenue to show genuine care. Since the applicant knows they’re not going through AI, they are free to optimize their application for a human reader. Hell, they actually are encouraged to go the extra mile with their application.

What’s in it for a hiring company? I reckon it wouldn’t make sense for a candidate to pay for mass applying, so they’d do that only for jobs they actually care about. So the hiring company gets a token of care along with a resume. Recruiters can still assess skills the way they do, but before committing any effort in interviews, they clearly know which candidates consider the position a great match.

So, would you pay to guarantee your resume is reviewed by a hiring manager? If so, how much?

Here’s a little experiment that’s in the spirit of the post. This link here is a token of human effort behind the post.
웃https://okhuman.com/CuC1uw

The post Would You Pay to Have Your Resume Read? appeared first on Pawel Brodzinski on Leadership in Technology.

A lot of what’s happening in the IT industry feels like we’ve been reinventing the core principles that the rest of the world has already figured out. Like, centuries ago.

Small Business versus AI Startup

Do you know of a restaurant that’s been losing money for an entire first decade of its operations, and yet remained open? Or any small business in such a situation?

Unlikely. If you do, it’s probably a hobby business of someone sufficiently rich not to treat it as an actual company.

So how about, say, OpenAI? For the first decade, it didn’t show a single dollar of profit. It raised close to $60B. Recent reports suggest that they burned through most of that money. And it’s not like profitability is around the corner. Sam Altman mentioned profitability in 2029 or 2030, which many experts question as doubtful. Not to mention recent hints about bracing for a hypothetical bailout.

It’s as if your corner restaurant were bleeding 6-digits a month, and somehow still operated because the chef had plenty of charisma. Oh, and once the charisma eventually wears off, the mayor would definitely buy out the failing business, right?

If the restaurant scenario sounds absurd, that’s because it should. In the tech industry, we are indeed that far from any sensible business principles.

Tech Startup versus AI Tech Startup

One could argue it’s always been so. VCs were always a rogue player, actively devastating the rules of the game for startups (for their own gain and startups’ detriment).

However, save for the internet bubble, investors’ expectations were at least somewhat connected with what an old-school, boring, brick-and-mortar business had to endure.

As a context:

• Google was profitable in the year 3.
• Facebook, which started with no monetization plan whatsoever, generated profit in year 6.

All that in a super-privileged IT industry, which provides a ton of leeway.

Compare that with (optimistically speculative) 15 years for OpenAI.

Again, as a context:

• Google raised around $36M.
• Facebook, with its super-aggressive pre-IPO global expansion, raised around $2.3B.

Compare that with close to $60B for OpenAI (and nowhere close to the end of funding rounds).

And we aren’t comparing it to your corner restaurant anymore but to similar giga-unicorns. If the comparison seems absurd, that’s because it should.

AI in the Corporate World

Of course, the explanation is the expected growth trajectory. “Once these companies start making money, it will be unprecedented,” they say.

OK, I’ll bite. Let’s assume I believe in the growth plans. A valid question, then, is: Where will these new revenues come from?

Interestingly, the corporate world, despite enthusiasm, sees 95% of AI initiatives failing to generate return on investment. And while corporate coffers are semi-infinite, we shouldn’t expect much recklessness on the old-school CFOs’ account (they’re old-school after all, they believe in the ancient principle that the business should actually make money). If there’s little to show for it, the investments will remain limited.

Sure, no one wants to be a laggard. Toe-deep AI attempts will keep happening. It’s just not something that could serve as a vehicle to bring hundreds of billions in revenue to AI companies.

AI in Software Development

Obviously, AI is all the rage in software development.

You’d see vibe-coding companies dubbed as the fastest-growing startups ever. As impressive as the revenue trajectory is, I challenge the notion that these businesses are healthy or sustainable.

You’d see product companies reporting a dramatic increase in ARR per employee (Annual Recurring Revenue per full-time employee) thanks to AI.

Shopify, which says “reflexive AI usage is now a baseline expectation”, has seen the figure explode to $1.3M ARR per employee. Jason Lemkin from SaaStr pointed out that the company has 30% fewer employees compared to 2022 yet is generating double the revenue. (My quick math indicates ARR per employee tripled during that period.)
Kyle Poyar

In reality, it has little to do with AI. Shopify fired around 30% of its employees in 2022 and 2023, a painful adjustment following blatant overrecruitment during COVID. The layoffs were way before they could deliver anything AI or show the actual impact of AI-augmented development on their productivity.

In fact, Tobias Lütke announced that AI is a baseline requirement for Shopify employees only this year. Saying that it’s AI that’s behind the layoffs and, consequently, improved revenues per employee is making stuff up retroactively (a.k.a. bullshit).

That’s a common strategy, by the way. It allows dodging the responsibility for wild overhiring and then letting people go as a result. Now, the tech bros say, “It’s not us that lay you off; it’s AI.”

If we look at the big picture, we don’t see a dramatic increase in products developed, repositories created, games released, etc. We don’t see a change at all.

While AI adoption in software development is definitely a success story, it won’t be the growth engine that enables AI companies to achieve profitability. Not single-handedly.

AI in Customer Support

How about customer support then? Automating customer support seems like a slam-dunk AI application.

Klarna reportedly was able to fire 40% of its workforce as they replaced humans in customer support with AI bots. Except two years down the line, they realized how much their customer support sucked and made an attempt to rehire many of the specialists they’d axed. With very limited success, let me add. Karma is a bitch.

It sure looks good in a spreadsheet when you show short-term savings from firing a bunch of customer support consultants. In the long run, it’s a downward spiral of deteriorating customer satisfaction, increased stress for employees who remain, and attrition (of both customers and customer support representatives).

My recent experience with Spotify’s support (see below) is a case in point. To add insult to injury, the way they handle feedback tells me that they don’t give a damn.

But who am I trying to convince? Just recall your most recent interactions with AI customer support. How was it? Did you feel cared for?

As much as AI in customer support is here to stay, as it’s essentially IVR 2.0, we will “love” it just about as much as we love IVRs. We’ll still crave contact with a competent human on the other side who genuinely wants to help.

It will stay so, even if the machine could have solved the problem equally well (which it cannot because it doesn’t think). You know why?

Because we’re wired for connection.

Customer support is probably the most vivid example, but the observation applies anywhere where we aim to substitute human interactions with AI. Sure, we’ll keep trying, but the results will remain varied at best, awful at worst.

We simply won’t rewire our brains to stop looking for human connection. Not fast enough.

AI in Content Generation

How about content generation, then? We can now generate text, pictures, videos, and music, all of which, with a little bit of luck, can pass as human-created.

We already have AI-generated music to land (reportedly) a $3M deal. A quick trip to LinkedIn will drown you in AI-generated posts. I’m afraid even to look at other social media.

Here’s a thing, though. Even if all of that stuff was good, there’s no way to consume it all.

We can have 100x as many posts, Instagrams, YouTube videos, LinkedIn posts, and what have you. We still have only 1x as much attention. The day still has only 24h.

That, by the way, applies as much to products. Even if it were possible to vibe-code all these hypothetical new apps (it is not), it’s not like we’d have 100x as many potential customers. It’s not that we have 100x as much time to use these products either.

That, by definition, creates a ceiling on how much stuff we can sustainably generate and still make money from.

If we go further, we’ll create tons of AI slop and make entire spaces toxic. Think of social media flooded with reels of guardian dogs. For a short while, it will generate some good ad money, but then we will move on, understanding that none of this is authentic.

A resume-based hiring process is another good example. This time, it is a process that we actively need (unlike watching a non-existent hero dog). And yet, by now, I genuinely dread the idea of publishing a job ad. Just imagine tons of AI-generated applications coming from random people all over the world. We’ll probably rely on trust networks to circumvent that.

While we will see a lot of AI usage in content creation, it won’t lead to an exponential growth engine for AI tools. Simply because wherever it’s extensively used, it leaves a toxic landscape behind. That’s the direct opposite of sustainability.

A Non-Obvious Answer to Why the AI Bubble Will Burst

I started the post by mentioning how IT has learned the lessons that businesses need to make money, and that social connection is essential.

If we look at AI (as a business) through these lenses, the picture we see has to be grim. The sheer scale of the revenues AI businesses need to generate to defend absurd valuations doesn’t seem justifiable with current usage patterns.

AI adoption in many areas (content creation, customer support, etc.) goes against the basic human needs. They strip us of human connection. Thus, it is not sustainable.

The adoption in some other areas, like software development, even if more reliable in business terms, will not be enough to justify the bets everyone is making on generative AI.

So, here’s a non-obvious take on AI.

Because the AI business model relies on reducing social connections between human beings, it is not sustainable. Thus, there is the AI bubble, and it will burst.

That doesn’t mean LLMs don’t make sense or that none of the AI companies will make money (some AI startups already are profitable). It simply means that the industry as a whole is overheated. And since the only way forward for so many incumbents is to get heated even more (i.e., get even more money and burn it even faster), it can’t last.

Millennia of human social wiring tell me as much.

The post A Non-Obvious Answer to Why the AI Bubble Will Burst appeared first on Pawel Brodzinski on Leadership in Technology.

That is, “funny” as long as you’re not a customer of said services trying to do something important to you. I know how frustrating it was when Grammarly stopped correcting my writing during the outage, even if it’s anything but a critical service to me.

While AWS engineers were busy trying to get the services back online, the internet was busy mocking Amazon. Elon Musk’s tweet got turbo-popular, quickly getting several million pageviews and sparking buzz from Reddit to serious pundits.

Admittedly, it was spot on. No wonder it spread like wildfire. I got it as a meme, like an hour later, from a colleague. It would fit well with some of my snarky comments about AI, wouldn’t it?

However, before joining the mocking crowd, I tried to look up the source.

Don’t Trust Random Tweets

Finding the article used as a screenshot was easy enough. It was a CNBC piece on Matt Garman. Except the title didn’t say anything about how much AI-generated code AWS pushes to production.

Fair enough. Media are known to A/B test their titles to see which gets the most clicks. So I read the article, hoping to find a relevant reference. Nope. Nothing. Nil.

The article, as the title clearly suggests, is about something completely different.

I tried to google up the exact phrase. It returned only a Redit/X trail of the original “You don’t say” retort. Googling exact quotes from the CNBC article did return several links that republished the piece, but all used the original title, not the one from the smartass comment. It didn’t seem CNBC had been A/B testing the headline.

By that point, I was like, compare these two pictures. Find five differences (the bottom one is the legitimate screenshot).

So yes, jokes on you, jokers.

Except no one cares, really. Everyone laughed, and few, if anyone, cared to check the source. Few, if anyone, cared to utter “sorry.”

Trustworthiness as the New Currency

I received Musk’s tweet as a meme from my colleagues. It went through at least two of them before landing in my Slack channel. They passed it with good intent. I mean, why would you double-check a screenshot from an article?

It’s a friggin’ screenshot, after all.

Except it’s not.

This story showcases the challenge we’re facing in the AI era. We have to raise our guard regarding what we trust. We increasingly have to assume that whatever we receive is not genuine.

It may be a meme, and we’ll have a laugh and move on. Whatever. It won’t hurt Matt Garman’s bonus. It won’t have a dent in Elon Musk’s trustworthiness (even if there were such a thing).

It may be a resume, though. A business offer. A networking invitation, recommendation, technical article, website, etc. It’s just so easy to generate any of these.

What’s more, a randomly chosen bit on the internet is already more likely to be AI-generated than created by a human. Statistically speaking, there’s a flip-of-a-coin chance that this article has been generated by an LLM.

It wasn’t, no worries. Trust me.

Well, if you know me, I probably didn’t need to ask you for a leap of faith in the originality of my writing. The reason is trustworthiness. That’s the currency we exchange here. You trust I wouldn’t throw AI slop at you.

If you landed here from a random place on the internet, well, you can’t know. That is, unless you got here via a share from someone whom you trust (at least a bit) and you extend the courtesy.

Trust in Business Dealings

The same pattern works in any professional situation. And, sadly, it is as much affected by the AI-generated flood as blogs/newsletters/articles.

When a company receives an application for an open position, it can’t know whether a candidate even applied for the job. It might have been an AI agent working on behalf of someone mass-applying to thousands of companies.

While we’re still beating a dead horse of resume-based recruitment, it’s beyond recovery. Hiring wasn’t healthy to start with, but with AI, we utterly broke it.

A way out? If someone you know (or someone known by someone you know) applies, you kinda trust it’s genuine. You will trust not only the act of applying but, most likely, extend it to the candidate’s self-assessment.

Trust is a universal hack to work around the flood of AI slop.

Outreach in a professional context? Same story. Cold outreach was broken before LLMs, but now we almost have to assume that it’s all AI agents hunting for gullible. But if someone you know made the connection, you’d listen.

Networking? Same thing. You can’t know whether a comment, post, or networking request was written by a human or a bot. OK, sometimes it’s almost obvious, but there’s a huge gray zone. In someone you trust does the intro, though? A different game.

The pattern is the same. Trust is like an antidote to all those things broken by AI slop.

Don’t We Care About Quality?

Let me get back to the stuff we read online for a moment. One argument that pops up in this context is that all we should care about is quality. It’s either good enough or not. If it is, why should we care who or what wrote it?

Fair enough. As long as consuming a bit of content is all we care about.

If I consider interacting with content in any way, it’s a different game.

With AI capabilities, we can generate almost infinitely more writing, art, music, etc. than what humans create. Some of it will be good enough, sure. I mean, ultimately, most of what humans create is mediocre, too. The bar is not that high.

There’s only one problem. We might have more stuff to consume, but we don’t have any more attention than we had.

Now, the big question. Would you rather interact with a human or a bot? If the former, then you may want to optimize the choice of what you consume accordingly.

Engageability of our creations will be an increasingly important factor. And it won’t be only a function of what kind of call to action a consumer feels after reading a piece, but also whether they trust there’s a human being on the other side.

It’s trust, again.

Trust Networks as the New Operating System

Relying solely on what we personally trust would be impractical. There are only so many people I have met and learned to trust to a reasonable degree.

Limiting my options to hiring only among them, reading only what they create, doing business only with them, etc., would be plain stupid. So how do we balance our necessarily limited trust circle with the realities of untrustworthiness boosted by AI capabilities?

Elementary. Trust networks.

If I trust Jose, and Jose trusts Martin, then I extend my trust to Martin. If our connection works and I learn that Martin trusts James, then I trust James, too. And then I extend that to James’ acquaintances, as well. And yes, that’s an actual trust chain that worked for me.

By the same token, if you trust me with my writing, you can assume that I don’t link shit in my posts. Sure, I won’t guarantee that I have never ever linked anything AI-generated. Yet I check the links and definitely don’t share AI slop intentionally.

If such a thing happened, it would have been like Musk’s “you don’t say” meme I received—passed by my colleagues with good intent.

The degree to which such a trust network spans depends on how reliably a node has worked so far. A strong connection would reinforce its subnetwork, while a failing (no longer trustworthy) node would weaken its connections.

Strong nodes would allow further connections, while weak ones would atrophy. It is essentially a case of a fitness landscape.

New Solutions Will Rely on Trust Networks

The changes we’ve made to our landscape with AI are irreversible. In one discussion I’ve had, someone suggested a no-AI subinternet.

It’s not feasible. Even if there were a way to reliably validate an internet user as a human (there isn’t), nothing would stop evil actors from copypasting AI slop semi-manually anyway.

In other words, we will have to navigate this information dumpster for the time being. To do that, we will rely on our trust networks.

Whatever new recruitment solution eventually emerges, it will employ extended trust networks. That’s what small business owners in a physical world already do. They reach out to their staff and acquaintances and ask whether they know anyone suitable for an open position.

Content creation and consumption are already evolving toward increasingly closed connections (paywalled content, Substacks, etc.), where we consciously choose what we read and from whom. Oh, and of course, the publishing platforms actively push recommendation engines.

Business connections? Same story. We will evolve to care even more about warm intros and in-person meetings.

Eventually, large parts of the internet will be an irradiated area where bots create for bots, while we will be building shelters of trustworthiness, where genuine human connection will be the currency.

Like hunters-gatherers. Like we did for millennia.

The post Trust Networks as Antidote to AI Slop appeared first on Pawel Brodzinski on Leadership in Technology.

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.

The post We Will Not Trust Autonomous AI Agents Anytime Soon appeared first on Pawel Brodzinski on Leadership in Technology.

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

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.

The post Care-Driven Development: The Art of Giving a Shit appeared first on Pawel Brodzinski on Leadership in Technology.

Historically, we asked for small code samples as part of job applications. The goal was to filter those who knew the basics from those who just aspired to become developers eventually. Granted, it wasn’t a cheat-proof, but that wasn’t the goal.

It was enough to tell the basics:

• Was it more toward a naive solution or more toward the optimal end of scale?
• Were there tests, and if so, what kind of them?
• What about readability?

Sure, you could ask a developer friend to write it down for you, but you’d eventually show a lack of competence at the later stages. Heck, we even had a candidate asking for a solution at a discussion group. But these were fairly rare cases.

Recruitment in the AI Era

So it’s late 2023, and we know the trick won’t work anymore. ChatGPT can generate a reasonable answer to any such challenge. Eventually, we decide against any coding task and simply ask to share a public GitHub repo. Little do we know, we’re way deeper in hiring in the AI era rabbit hole than we could have ever dreamed.

Sure, we understand that people will feed ChatGPT with our job ad and have it generate output. After all, as always, we provide a great deal of context about what we want to see in the applications. That makes LLM’s job easier.

We state explicitly that we seek genuine answers, and we’ll discard those blatantly generated with ChatGPT. Also, no LLM is an expert in who the candidate is, right? No LLM is an expert in me.

We’re a small company. Till that point, our record was around 90 applications for the internships. Typically, it was maybe half of that. This time, we receive almost 600.

Despite all our communication, most of them were generated by ChatGPT.

AI as the First Filter

OK, it’s no surprise. Instead of creating thoughtful and thorough answers to 4-5 questions, each taking at least a couple of paragraphs, now we can just feed an AI model of our choice, and it will produce as much text as anyone needs.

Companies response? Let’s use the same models to tell which resumes we should even read. Otherwise, it’s just too many of them.

And yes, in our case, I read each and every one of those 600 applications. Well, at least the parts. If the first paragraph has “AI-generated” painted all over it, and the question literally asked you not to generate your answers, then my job was done. I didn’t need to continue.

By the way, the next time I will do the same. However, we are oddballs. It’s now the norm for the first filter to be an AI model that decides whether to pass an application on to a human being.

In other words, the candidates generate applications with AI to pass through an AI filter.

Do you see the irony?

Just wait till someone starts putting hidden prompts in their resumes. Oh, wait, someone has definitely tried that already. I mean, if the researchers do that in a much more serious context, applicants trying their luck is an obvious bet.

Hiring Noise

Now, extrapolate that and ask: What does the endgame look like? More and more noise.

Let’s just wait till we have AI agents that automatically apply to jobs on our behalf with no human action needed whatsoever. Oh, who am I fooling? There already are plenty of startups pursuing this path.

The promise is that you will be able to send hundreds of applications in one click. That’s great! You increase your chances! Or do you?

Even if you do, it will only work for a very short time. Then everyone else will start doing the same, and suddenly every hiring company is flooded with tons upon tons of applications.

What will they do? Yup, you guessed it. They’ll pay another AI startup to automate this job away. Most likely, they already have.

We can easily increase the number of CVs flying over the internet by a factor of 10x or 100x. We still have only 1x of attention from hiring managers.

The AI Era Hiring Game

The early stages of recruitment will increasingly be like two AI models playing chess (while neither having an actual model of what a chess game is). One will try to outplay the other.

An agent playing on a candidate’s behalf will try to write an application that will pass the filters of a hiring company’s agent. The latter, in turn, will attempt to filter out as many applications as possible while still keeping a few relevant ones.

Funnily enough, I’m guessing that what will make you pass through the AI filter will not necessarily be the same things that would make you pass when a human being reads your resume.

LLMs optimize for the most likely output. So “standing out” isn’t necessarily the optimal strategy.

I remember when an applicant drew a comic book for us as their application. It sure caught our attention. I bet an AI model would dismiss it. Oh, and yes, she ended up being a fabulous candidate, and we hired her.

Which doesn’t mean drawing a comic book guarantees you a job at Lunar, of course.

If we were to believe startups operating in the recruitment niche, these days, hiring is just a game of volume. Send and/or process more resumes, and you’ll find your perfect match.

What Is a Perfect Match?

I’ve been recruiting for more than two decades. I’ve made my share of great hires. I’ve made a lot of mistakes, too. Most importantly, though, I’ve made oh, so many good enough hires who have ultimately turned out to be excellent later on.

It doesn’t matter how extensive your hiring procedures are. After a week of close collaboration, you will know about the new hire more than you could have learned throughout the whole recruitment process.

Applying for a job is like submitting an abstract for a conference’s call for proposals. A great talk description doesn’t mean that the session itself will be great. It just means it is a good abstract. And that the person who submitted it is probably good at writing abstracts. It tells little about what kind of speaker they are.

By the same token, a great resume is just that. A great resume.

What we’re doing in recruitment with AI is we set almost the whole limelight on the applications. It becomes a game of writing and analyzing CVs.

Last time I checked, no company was trying to find a person who was great at writing resumes (or more precisely: getting an AI model to generate a resume that another AI model would like).

Renaissance of Good Old Coding Interviews

It’s no surprise that physical coding interviews are gaining popularity again. Increasingly, using the AI tooling of choice will be allowed and encouraged during those. Ultimately, that’s how developers work every day.

After all, these interactions were never about knowing the answer. OK, they should never have been about the answer. They should have been about how a candidate thinks, iterates their way to a better solution, and when they deem it good enough. They should have been about working together with another professional. About all those intangibles that we don’t see unless we have an actual experience of working together.

We will see more of those. And there will be more of those happening on-site, not remotely. As a hiring person, I want to understand what part of someone’s train of thought is their creativity and what came as copypasta from ChatGPT (or Claude Code, or whatever).

There’s no shortage of code-generation capabilities. We still don’t have a substitute for judgment, though.

Why Is Hiring Broken?

So far, so good, you could say. We return to proven tools and focus on what really matters.

Yup. That is as long as we’ve cut through the noise. Next time we open internships at Lunar (and we will), I expect more than a thousand applications. Sure, many will be crap, but there will be plenty of work to figure out which will not. The effort needed to navigate the noise grows exponentially.

Under the banner of “we are improving recruitment,” we actually did a disservice to both parties that play the hiring game. Candidates complain that they send lots and lots of resumes, and they don’t even get any responses anymore. Hiring companies have to deal with a snowballing wave of applications, which means that finding a great match is nearly impossible.

That much for good intentions and improvements.

All it took was to remove the effort required to prepare an individual job application. The marginal cost of thinking of and typing those five answers in a form is gone, and thus we can spray our resumes everywhere with one click of a mouse.

Thank you, AI, for breaking the hiring for us.

(And yes, I know it’s all us, not AI.)

The post AI Has Broken Hiring appeared first on Pawel Brodzinski on Leadership in Technology.