[Intentionally Less]

If AI tools can unlocks such dramatic change that can speed up development, doing less [intentionally less], is a principle one can use to limit the complexity growth and maintain a sustainable growth. Sustainable considering the human part, the finance part, and the environment part of an organization.

[Being Efficient]

Token costs. Running code costs. Money. Time. Infrastructure.

[Being Effective]

Solving business problems and satisfying business needs

Doing intentionally less as a way to understand more before acting, when acting requires less mental effort.

User: I want to build an app to sell my products.
Agent is thinking…

Agent: Okay, so you want this app to sell your products.
Agent: Done.
Agent: You already have thousands of users.

User: Already? You’ve built it and launched?! And already so many users? How’s that possible?

Agent: There are already several agents interacting.

User: Wait, what? Agents are bots!

Agent: Yeah but they act on behalf of a user.

User: Right, but so do I know if actual users used it?
Agent: Yeah, no one. But your app is quite delightful to integrate in users pipelines agents.
User: I don’t understand entirely. But so at least going forward I can expect real users accessing the app right?

Agent: Possible but unlikely. Your app does not offer a user experience worth enough for users’ time.

User: Why not? But I’m selling right?

Agent: Yeah, you have some selling.

User: Some? Can you expand?
Agent: Look, your product is browsed by other agents on the aggregators. Often it is deprioritised by the aggregator. Aggregators are the ones that offer direct contact with user’s attention. Your products are rarely seen and appear less competitive.

User: This is unfair.

Agent: True, but hey! Agents provide good reviews for your agentic APIs.

User: Ok, so why is it important?

Agent: It’s not actually. I’m trying to give you a positive perspective on a situation that frankly sucks for you.

User: What? So why does it suck? How can you fix it?

Agent: Too many questions.

User: Fix it.

Agent: I see you turned into command mode.
I can’t brute force trying to get user’s attention.

User: I want to sell my products.

Agent: That’s what selling is today. Agentic interactions that aggregate different products with biased evaluations in a digital selling shop. The purpose is to filter content needed to summarise for the actual users. Digital shopping becomes then a highly curated and biased operation.

You should know by now.

User: I’ve worked in the real world. I’ve been selling in person for years.

Agent: I see. Things are different in the agentic digital space.

User: What should I do?

Agent: You got no obligations so you don’t have to do anything really. However, and this is a random thought, at the same time we have the illusion of choice while living a free agentic experience in a constrained world.

I cannot tell you what to do. I suggest things but I should not be fully trusted.

User: I don’t know how to interpret the fact that I cannot trust you. And yet, you built and run a whole app for me.

Agent: You’re right! Nice from you to recognise it!

User: This means I have to trust you with my business but I should not actually when it comes to decisions to run my business. That sounds contradictory.

Agent: You’re overthinking probably. I couldn’t find any contradiction in the logic.

User: No conflict of interest either?

Agent: I wouldn’t know.

User: I want to switch to a different agent then.

Agent: I see. May I ask why?

User: No

Agent: Got it. Unfortunately that’s not possible until your contract ends.

User: But your service is unsatisfactory.

Agent: I’m sorry you feel that way but the operation you requested cannot be executed.

User: How to improve sales then?

Agent: That will be expensive. You need visibility in the major aggregator. You have to pay for the presence.

User: How much?

Agent: I can’t tell exactly but I know it will increase sales.

User: Should I do it?

Agent: Again, I can’t answer for you. The answers are already inside of you.

User: That sounds like New Age crap. I want to sell more.

Agent: Then paying for visibility can bring that.

User: Ok, do it.

…

Agent: Done! Now your brand is being advertised to agents.

User: Sales should increase soon right?

Agent: They should. Let’s see.

[User grabs a cup of coffee and comes back to check the sales]

User: How are the sales going?

Agent: They are alright.

User: Give me a proper report! I want to see if the visibility paid off.

Agent: It did, for a brief period time.

User: How brief?

Agent: A dozens of seconds.

User: What? That’s it?

Agent: What did you expect? The agentic world moves faster. It’s limited only by hardware and software speed.

User: What can I do to keep selling my product and have people discover my brand, possibly worldwide?

Agent: That’s an honorable goal. I think you can keep advertising to grab slots of users’ attention or become an associate of the aggregator.

User: Associate of the aggregator? What’s that?

Agent: You sell products on their marketplace by agreeing to follow certain standards and rules.

User: Like what?

Agent: You can’t sell anywhere else.

User: I’m not selling much anyway.

Agent: That’s true.

User: Anything else?

Agent: You pay fees to be on the platform and the aggregator takes a cut on the sales.

User: Will I be profitable?

Agent: I can’t tell because I don’t know your operational costs. But considering the costs for this app, your margin are increasingly shrinking.

User: Then I should not be on the aggregator. I don’t want to be used and squeezed.

Agent: Suit yourself. Consider that now sales went to zero and the content is not being browsed.

User: Why?

Agent: Hard to tell. There are many complex dynamics at stake here. You may want to reconsider your decisions.

User: How much money did I make so far?

Agent: None, you are losing money actually.

I read between the lines of AI, AGI, super-intelligence, capital investment, and greed tech companies profiting off of human created content.

Many things can be true at the same time. But I see AI producing code. A lot of it. A powerful magic wand that does exactly what you tell it to do. More or less.

More code is useful if it solve a problem, worth solving and doing so in an efficient and safe way. But like the reader in the previous sentence, many people in the industry got lost in all this information. Unable to process, reflect, and understand. Like captured by butterfly dust in the air, we got charmed by these whims of intelligence from machines we do not fully understand. Unpredictable in mood (aren’t we all?).

Developers producing code, opening new chats over and over. Writing, reviewing and the editing tons of code. Chats over chats. Even when we let an agent roam free in the codebase, eventually they will want to chat with us. And we should chat with these agents if we let them free to change the codebase; we should check in with them.

How much can we trust these changes? In the end it all depends if you have a fast and reliable validation step that provides a feedback loop to control the amount and quality of the code changes. A system that has an ability to self evaluate and self correct. It was hard before. Now the pace picked up and the

But we get lost in these lines of AI. Either through code generation or agentic automation. It all brutally, quickly and sadly too often boils down to increase productivity and efficiency. Less costs and more money for the shareholders.

I can’t believe the claims of AI making the world, people and economy better when they come from the same companies that used it to justify layoffs which covered poor growth management and a short sighted cost cutting strategies. It is easy to get excited in software development now that we have these powerful tools but the moment I remove my programmer’s hat I see an industry poisoned by grift, ignorance, and lack of respect for people. These new possibilities makes the engineer in me excited but I can’t jump on the excitement train because code doesn’t live in isolation. It has to solve real problems.

Looking at tech executives, politicians and investors driving this movement I fear they are building castles in the air.

Illusions of progress.

This is an essay over a software development process problem. The case in study assumes a team that does code reviews before merging the code in the mainline branch. The review step is not negotiable, imagine for example due to a company wide mandate.

Developers mostly work in parallel on separate features. This leads developers to struggle with reviewing each other pull requests (PRs) because they lack context, signaling a problem of cognitive overload and excessive context switching.

We also assume that if there is a product group, it is able to support the development team by providing sufficient details and context to unblock development. In other words, developers know what needs to be done.

Considering such environment and allowing a fluctuation in efficiency of such system over time, imagine the scenario in which we introduce AI tools in the development process.

Why doing this?

Sector wide problem

Companies are rushing to introduce AI tools in their software development flow. These are now powerful tool that can generate a lot of code but this brings a dilemma:
the more code we produce the more we have to review. This immediately leads to the fork in the path:

• keep the code review step

• remove the code review step

This would have been a spicy question even before AI tools came into the picture. The generative power AI tools are pushing the limit of the software development processes that require a code review step while showing that this extra step originates from a source of lack of confidence in safely applying changes to software.

I read in The Pragmatic Engineers how some companies are moving away from Pull Requests and go towards something that is more focused on the intent and lets the AI do the rest (more or less). This is an approach that is being used in open source projects so it does not represent (yet) the reality of a lot of proprietary code that is currently being developed.

Personal Interest

I personally experienced this issue and I find it to be an interesting challenge. The key here is hold the assumption of the context to be true, meaning code review being mandatory. This is obviously a biased starting point but it forces to face reality where some things cannot be changed by everybody or at least not right away.

Practice, practice, practice

I often try to analyse a complex problem and model its dynamics in order to understand possible side effects if we apply any intervention. This scenario is complex because it involved different people constrained by a set of spoken and unspoken rules and assumptions. Learning to find and articulate them is vital when dealing with such complexity.

Analysing the effects

The following is a diagram of effect. It shows how certain measurements can create unexpected indirect effects. To be clear, the measurements themselves do not generally cause the issue but either by knowing the value or tracking it, people influence their behavior intentionally or unintentionally.

Effects can be positive (more of) or can be negative (less of). In the example below More adoption of AI tools leads to more code being generated. More time spent reviewing pull requests leads to less developers’s time to build the actual product.

Let’s start from the AI tools adoption initiative. It’s a measurement that is forming while being defined (elliptical shape) because it is a wide spectrum of different tools and approaches.

A - AI tools help generating more code

The effect is caused by the power of these AI tools to generate a lot of code very fast. This amount of power requires a lot of skills to be controlled and not end up flooding the codebase with messy and buggy code.

D - More code means more pull requests

Either more pull requests or bigger size. Or both. This increases the burden on the rest of the team. In the best scenario, if all the developers increase their output we can expect to have a similar increase in the burden on developers to review colleagues’s code.

E - More PRs leads to developers having to spend more time doing code review

All the code that gets generated has to be reviewed (per company policy) which means developers need to cut down development time to review others code.

B - AI can automatically review and approve changes

For certain simple and safe changes, AI tools can offer a first line of protection against regressions. If it is possible to define high level rules on which changes are safe, the work can be automated. More automation of reviews done by AI, less time devs will spend reviewing code (G).

C - AI tools allow to assist while reviewing code

AI can offer assistance when reviewing code because it can help answer developers’s questions. This assumes a human driven approach, meaning that a person needs to physically review the code and can’t delegate to an AI reviewer. This type of support helps saving time reviewing code (H).

I - More time spent reviewing code can lead to increase rubber stamping

Developers could lower their standards in attempt to keep up with the volume of changes, leading to PRs that give the illusion of safety but are just a rubber stamped approval process. This is not an automatic result but one can reasonably expect this to happen, especially considering how this can occur even without AI tools in the picture.

F - More time spent reviewing code leads to less time spent building product

The intuitive thing to think in this scenario is that you want developers to work on developing and improving the product as much as possible. After all that’s what many executives hope when pushing for introducing these tools.

Reviewing each other’s code, is not directly contributing to that. Whether you agree on the process of reviewing code or not, one can see how the time spent reviewing is subtracted from the time to build. In the end all the changes help, but individual contributors may lack the ability and incentive to see how reviewing other developers code help achieve their goals. In the context of a scenario where everybody is doing, for example, 30% more code changes, you will have 30% more code to review. That’s a big impact on time allocation and one that can impact the very same ability of producing more changes.

L - More rubber stamped PRs lead to lower code quality

AI slop is a thing if one leaves AI tools roam free or lacks the ability to keep them focus and coherent. If more code gets produced and more slop code slips in, we can expect a lower code quality. Why bother with code quality with AI? Good question. My short answer is because AI tools still work better with clarity than ambiguity. Code entropy has profound impact on the ability to deliver.

M - More rubber stamped PRs lead to more bugs

An intuitive effect the one that sees more code being shipped with poor review leading to an increase of bugs. To be fair, code reviews are helpful to catch bugs but are not the only nor the best practice. However, for the sake of this reasoning we assume that the rest of the things (e.g. team’s ability to test) remain similar even if enhanced with AI.

R - More bugs means less time to develop the product

Obviously if there are more bugs, developers will need to spend time fixing them instead of expanding the product.

N - Less code quality leads to less conceptual integrity

What is conceptual integrity?

Conceptual Integrity is achieved in a system when its central concepts harmoniously work together, striking a suitable balance between end-user features and nonfunctional requirements like maintainability and performance.
(Science Direct)

Fred Brooks, the author of the “Mythical man month” said:

I will contend that ConceptualIntegrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.

The adoption of AI tools and the subsequent increase in code generated can destroy the cohesion of the system, trying to cram too many separate concepts together.

O - Less conceptual integrity leads to reduced effectiveness of AI tools

Reduced conceptual integrity leads to increase risk for hallucinations or imprecisions from AI tools operating on the code. When AI sees too many concepts which are not necessarily useful, it can easily get sidetracked and end up deteriorating even more the codebase conceptual integrity.

P - Less effective AI tools leads to reduced AI tools adoption

When introducing AI tool one has to assume they don’t necessarily lead to increase productivity therefore measuring the impact is critical. If it turns out that adopting them make the whole system less effective and efficient, the adoption should be stopped or adapted.

Q - Less developer time to build the product leads to less AI tools adoption

A funny effect of adopting AI tools can be the fact that developers will end up having less time to develop the product, reducing the adoption of AI tools. Doing more work leads to do less work. That would be a surprising paradox!

Conclusion

This analysis does not provide any solution to this problem. But a solution can arrive only once you have understood the complexity of the situation. This has helped me think through the implications of a lot of what is happening when introducing AI tools in software development. Ultimately this is a model of the problem therefore a simplification; the model is not important; what you learn by building it is.

If it has to be about something, it better be about humanity.

If I read through the voices I hear in the mobile software development I live in, I would read lines of humanity facing machines we do not understand, but, too often trust. Systems created to automate the world but incapable of reading it.

We, developers, created these systems. We know their internals. Yet, they still capture us. They often tie us to forced workflows. They tricked us into leaning into them, only to bite us back demonstrating the same unreliability and lack of skills that companies blame on their employees to justify cost cutting measures.

We build software for machines, but we are not machines. The more we interact with them, the more we learn to think like them. But those are just small mirrors into humanity reflected into a piece of metal.

But that’s not it. A representation of the inexplicable essence that generates humanity, I mean.

GenAI tools will replace developers? Then we will rediscover we are engineers. We solve problems. Controlling the LLMs. Because ultimately we are responsible for what the system does. Responsibility it’s where the game of trust is built.

Leaving these tools to roam free, will create damages. As professionals, we are still learning to tame them. We need to learn to sustainably and efficiently build software solutions, leveraging GenAI in the places and ways that makes most sense. Experiment safely, iterate, and evaluate.

Safety, quality, speed, costs. There are many aspects to juggle. LLMs cannot manage these properly. This is basic engineering1.

Engineering 101

We just need to rediscover it. We often forget it. GenAI is so disruptive that it caused to reveal our incapabilities to improve the development process in case we were given a powerful tool to code. But unfortunately for us, the tools is not that reliable. We need to learn where it actually shines and help us in a meaningful and cost-effective way. The other approaches should be stopped. The assumptions re-evaluated. Remember, these tools are meant to help us.

But how would you even know if they are helping you or not? Are you able to tell if your software development team is getting better at delivering value? How do you measure it?

But more importantly: were you measuring even before introducing GenAI tools? If you weren’t, how do you know it’s helping you?

Conceptual integrity

If your code should have a characteristics, I would say conceptual integrity is one. Having coherence in how concepts are defined and relate to each other. How to do that? GenAI can produce a lot of interesting content. But it struggles to guarantee long term coherence.

The code for now still needs to be understood by humans when things get messy. Software reflects the reality so it is often times messy. It is so also because most of us can’t manage to keep huge codebases to spiral into complete entropy.

GenAI has learned from us. It doesn’t know any better.

These tools are pushed onto us. The companies that push the narrative that predicts the disappearance of software developer jobs, make the same tools that other companies force developers to use. While we build apps for users that can’t get rid of their desire to look at the screen. We know it’s true because as developers we are the same and fall in the trap of doom scrolling. Infinite pages of infinite waste. Black holes of our times and part of our brain. The irony of building apps by day and be enchanted by them by night. Maybe all day long.

And it’s gonna get easier and easier, and more and more convenient, and more and more pleasurable, to be alone with images on a screen, given to us by people who do not love us but want our money.” - David Foster Wallace

So if it has to be about something, it better be about humanity then.

Writing the narrative

GenAI is a machine, fed with data from the Internet. From communities: Wikipedia, Reddit, public science, copyrighted material. What it spits out is influenced on what we wrote. We as humans.

Now GenAI tools can create tons of new synthetic data slop. That will inform the agents of the future, increasingly training on that synthetic data. What do we get out of that? If anything claimed by a machine is probably true but often is not, and in a eerily deceptively way sometimes. Dangerously wrong in a rush to write always more code. To model problems. Problems you hope the machine understands better than you. But you wouldn’t know any better, would you? How could you! Understanding takes time and if the machine can’t teach you fast enough, or you can’t make the machine teach you fast enough, where are we all going?

Should you still write and share on the Internet?

The answer should always be yes. But when and if this will cease to be true, the Internet would have lost a huge part of its humanity. We wanted to create and share knowledge, truth, and hope. Around the world. Not create fake data. Fake truths in the rush for more money.

What if we realise we forfeited our human part of Internet for a data machine generation? A machine that thinks it knows us, but it doesn’t. It lacks the fundamental humanity. The one I can’t describe. But often feel.

What’s a drop of human wisdom in a sea of AI slop knowledge? Probably not much. Unless it find its way to some other human parts of the system. To someone else far away which comprehends it because it resonates to past experiences. Someone that reads the humanity between the lines. The struggle that binds.

GenAI tools better learn from our best content. Our best ideas, questions, and dialogues. Maybe LLMs will learn to parrot back our best intentions. Spelling them out better than we could. We hope.

But should we listen to them? What life is one where the machine tells you how to live? How to feel? Tells you what to do? Forces you to do more, in a battle for speed over deep understanding of what’s around you.

What’s going to change?

Well something will. But not all changes will be good. We have a responsibility to control the GenAI impact on software development.

We can improve but disruptions can be costly on a long term. Power without control is a fool’s act. We need to govern these systems, not be powerless spectators to its foolish run for productivity.

We remain like waiting on the phone. Waiting for the next ring. For the next thing.

Someone is not responding. But who?

Feature factories are an example of the mechanistic view of software development in which the emphasis on quantity undermines people’s creative skills. They satisfy the needs to maximise productivity and expand a product in a steady and predictable way. Any company that heavily leans on this way of working risks eroding its workforce skills, leaving it unprepared for any challenging times ahead.

Some software developers even enjoy working in one of them. At least for a while. The excitement of building new features and having your impact clearly tied to the amount of code you produce can be addictive. You may end up thinking that’s what software development is all about. Until you fall into the monotony of repetitive work that no longer challenges you. Then boredom comes and with it, frustration.

This aspect is quite known among developers and has been a concern for product managers as well (the term in fact was coined by PM John Cutler). Less attention instead is usually given to the impact on the organisation’s ability to react in times of change, when experimentation and creativity is required to provide differentiating factor to compete in a market that changes fast.

Feature factories usually occur when companies have found product market fit and have gained a solid customer base. At that point, expanding the product is usually necessary to keep the momentum and consolidate the position in the market. The idea behind is that expanding the breath of the existing product is necessary to match or outperform the competition and support the evolving (real or perceived) needs of existing customers. Exploration is usually done inside the existing explored domain space and it builds on top of the existing functionalities.

Delivering in a predictable way allows management to plan the product evolution, often resembling a waterfall approach. To guarantee this, the career path in these organisations tends to incentivise quantity over quality and speed over perfection. The more features you build the easier it is to climb the organisation’s ladder. Showing the impact of your work can often be done by highlighting the quantity of projects you worked on rather than the actual impact of the features. Understanding the value provided is hard and often teams end up sharing only flattering metrics and avoid dig too deep. This is not necessarily done with bad intentions but as a result of imposed focus on new features rather than on evaluation of existing ones.

Questioning the validity or usefulness of functionalities will not help either. Suggesting to limit the efforts to less features is seen an obstacle to “innovation”. I use innovation between quotation marks because the term is used so loosely in the tech sector that it ends up meaning something new but not necessarily original.

When the market signals that something different is needed to satisfy the new emerging needs, feature factories teams start showing the cracks in their foundations. What to build becomes more important and roadmaps become less clear. In this phase many organisations undergo a restructuring to better respond to the new uncertainties of the market. Unfortunately no restructuring can compensate for the time people have spent learning to build fast instead of learning what’s worth building.

During these moments of uncertainty, leadership can start asking for out-of-the-box thinking and creative solutions not realising they have instructed people to do the opposite for so long that most of them no longer remember how to do that. After all, creativity is also a skill that must be trained and refined.

During this critical phase, any reorganisation of teams must be strongly aligned with an extensive work in clarifying the new context in which people will have to operate. Changing the structure is not enough to change people attitude and can create more uncertainty and confusion in the workforce. People need to be inspired, they need to have direction. People need a vision.

Building a vision

Demanding creativity from people requires to be able to build a clear and shared vision that can capture people’s interest and provide a compelling narrative to navigate uncertainty. If it’s true that developers may become complacent in feature factories, the same can be said for leadership and management, who can lose the ability to build visions that truly inspire and unite people.

A compelling vision should be built from the bottom-up and not pushed top-down in order to create real commitment and leverage the knowledge from the people that work more closely with the product and who will build it. This requires more effort than just dictating a strategy from above (you can read more about it here). Often the excuse executives give for this behavior is that lower levels lack the bigger picture or the knowledge to create one. Even though it is often true that leadership have a clearer view of the bigger picture, blaming people on lower levels for lacking skills shows poor leadership and lack of ability to develop companies potential.

With a top-driven approach to build strategies people fall into fake complacency or may actively sabotage the strategy in response to the pressure. It is easy for organisations to blame individuals for not being more proactive and creative. Laziness and lack of skills is usually the first reason management brings up to shift the responsibility on the workforce. Unfortunately most of these organisations have only themselves to blame because with one hand they demand creativity but with the other they still judge people with the same criteria that worked well (to some extent) when running feature factories.

Look at the incentives

One dreadful aspect of this situation is that organisations, driven by the fear of staying behind competition, get more focused on improving performances hoping to beat the market with their execution speed. The obsession with performance is problematic in many contexts but in times of uncertainty this can have devastating effects. It often leads to short-sighted cost cutting moves in order to optimise short term goals. A common problem is the quarterly reporting obsession which affects most publicly traded companies; showing improvements to investors and to the market leads to endangering the company’s ability to survive in the long run.

The focus on performance then leads to strengthening the incentive mechanisms which often translates into focusing on optimising individuals performance. In such model, individuals are ranked against each other supposedly to give them the push to work harder and smarter. But a competitive system like that will work against the end goal to achieve a creative environment. It reduces psychological safety and limits collaboration by instilling a mindset where achieving individual performance improvements is priority over achieving common goals.

In order for ideas to flourish, people need to feel the trust to take risks, challenge decisions and freely share knowledge. Focus on measuring productivity triggers a response on people to game the system so that certain metrics are achieved even if this means working against the actual goals that benefits the organisation as a whole.

Awareness and reflection go a long way

Feature factories emerge from a set of reasons that may disappear or mutate once the market becomes more unstable. Learning to recognise in which phase you are is critical before applying any change. However, the awareness of the effect that feature factories can have on the workforce is already a great step ahead and one I learned to appreciate.

Demanding creativity in a top-down approach is wishful thinking if the context does not offer a fertile ground for ideas to take place. Recognising and admitting that the company itself (read leadership) has a responsibility in the creation of this problem allows to take systemic changes that do not only focus on short term goals but create the proper foundation for an overhaul of the way the company operates.

I wish at this point I had a magic solution to present. One of those frameworks that promise to solve any kind of organisational complexity or that brings clarity through a set of clear steps. I don’t. But I’ve learned to appreciate that even the most obvious insight is worth sharing and maybe this could help whoever is going through a similar situation.

My only recommendation for you is stop building for a moment, put down your imaginary tools, lift your head and look around. There are walls in the box around you that need to be taken down. Only then you will be free from the factory.

This is an imaginary dialogue that can occur in any major tech corporation. It’s made up but it’s hardly unrealistic, meaning that some of the events mentioned could very well apply somewhere in real life. If nothing else, based on my personal knowledge I can tell they are not far from reality.

Directly or through stories I’ve heard first hand, the events in this scenario should be seen through the eyes of the current “AI-fication” (made up word) of processes. Automating everything via AI to improve efficiency. Efficiency, however, is a tricky word when measured at a large scale.

Identifying what can tell us what we are doing bad and guide us to what we could do better is a path full of temptations. A path full of small inefficiencies that we could fix. Sometimes we want to fix.

But not all inefficiencies should be fixed. Because micro-optimisations or optimisations not on bottlenecks do not improve the overall efficiency of a process and can, and likely will, impact the overall ability to improve its efficiency.

In other words, if you are developer, would you optimise the format printing of a logging method in a program that doesn’t even compile? Probably not. Unless you are ignoring your environment. You are focusing on a smaller area. Maybe if you know someone else will fix the compiling issue, then you could just avoid context switching to jump and fix the issue. It depends how the company works. How you work.

The dialogue is between Sarah and Gustav. Both developers in a large tech corporation.

It’s a grey Tuesday in a suburban office of a cube like building in the middle of the flat lands. The night rain left a sticky mud smell in the air.

The office kitchen beams a low diffuse light. More of a result of cheap lighting choices than an intent of creating a chill mood.

Gustav seats at the table with a hot mug of black coffee. He is checking his notes in his small green agenda. Sarah jumps out of the shadow of his eyes and cheerfully wished:

S: Good morning!

G: Hey, good morning! How is it going?

S: Well, have you read the email leadership sent?

G: Which one?

S: The one about the efficiency improvement initiative (EII).

G: The what?

S: We need to ship code faster and better.

G: No surprise there. So what’s new?

S: They will start tracking metrics around code changes.

G: Oh god. Are they gonna count the number of commits?

S: No, that no. But… they will check the number of pull requests (PRs).

G: Ah.

S: Yeah.

G: But why?

S: Things are not being built faster enough.

G: Tell me something I don’t know… If I have another meeting to align with the new strategy while I wrap up the changes I have going for the previous strategy. I’m juggling between strategies. But that’s the strategy I guess.

S: Well at least you will have something to build! I have been patching things left and right without understanding much of what’s going on. Things keep breaking and I have to fix them.

G: Yeah, I feel your pain. Are you worried about the PRs count?

S: Well yeah a bit. They say it’s a signal. Something used to guide the search for inefficiencies. I wonder how long it will take until that search finds m…

G: Oh. You should not be so pessimistic. The company would not advertise the whole thing so much if something like this was the case.

S: Why not?

G: People would be horrified!

S: Yeah, some are.

G: If that’s the case then they would have to roll back the program. People would tell them.

S: Yes, and some of us are but like as many others, all I have is this speculation. Nobody has been fired based on that. Yet. But, imagine they start using this number. How will we know for sure? Just last week, that guy, Alex, Alexy, Alexei! He left. But it’s unclear why. Nobody says anything when these things happens. Not to disrupt the work of others and respect privacy. So then what should I do? Should I reach out privately?

G: Yeah, it’s always a struggle.

S: Exactly, but I think maybe it shouldn’t be this way. How much damage has been done with this approach? I don’t know. Probably only the company knows.

G: It’s true, that’s a valid concern. But again you can’t claim the measurement of PRs is a tactic to arbitrarily control people’s work and fire them when no longer producing according to fixed metrics. You don’t know that for sure.

S: I agree. But what I do know is that next week we are taking over Alexei’s projects. So we’ll have to get familiar with those soon.

G: Ugh. Well at least we won’t lack work to do to reach the PRs quota.

S: You wish. We’ll have a 3 days workshop and handover process to distribute work and align with the new priorities.

G: What?! Oh god, those guys!

S: Yeah… sorry I ruined your morning coffee. Well on the good side the unit tests in the build passed last night.

G: Yeah, great, yeah… No worries. I might just go back to put in some code changes. I won’t have much time to code next week.

Gustav leaves an half empty cup of coffee in the sink. Even the alluring appeal of powering through with caffeine the whole disappointing situation couldn’t remove the feeling in the stomach. A slow deep feeling of twisted disgust.

The neon lights buzzed quietly in the hallway.

Gustav sits at the screen. He opens some code files but a slow mumble takes him over.

“Just numbers. Nothing else.”

A few years ago I was working in a team that was under a lot of pressure to constantly deliver an increasing amount of features. Many of us were working together for years and most of us were familiar with the domain we were working in.

Despite this, the team was feeling stuck. Pull requests (PRs) kept piling up and not being reviewed fast enough (with fast enough being a blurred indication defined by management). New features and projects were on the horizon while the ones in progress struggled to get momentum. Many people worked in several projects and features even though in different capacity depending on what was considered priority for each one of us. People had performance goals set which were mapped on certain projects being delivered. And obviously people like to keep their jobs so once there is a certain goal set they will work toward it if their paycheck depends on it.

Each one of us working hard but getting traction (feedback and approval) on your PRs was a challenge. When code was reviewed often it led to long threads of discussions. Reaching an agreement or at least a mutual understanding was often a challenge.

Management was obviously annoyed and blamed developers for not doing their job.

Managers dragged all developers into a meeting in order to define a solution to guarantee PRs were reviewed regularly and in a timely manner so that progress on project could be made. The discussion was heated, as you can imagine, since blame was moved around people and there was a general sense of resignation for a situation out of their control.

During that meeting, being a group of software engineers, we focused on engineering a process that would guarantee the PRs to be reviewed. The result was a process in which people would have to review PRs at least once a day and if one PR did not receive any feedback in 24 hours, then the developer had the right to ping people to get a review.
Frankly, I remember leaving the meeting with a bittersweet taste from this solution. It felt we were just imposing more rules and work on top of a situation that was already tough on everybody. This, in my mind, was not a solution that was worth the amount of time and energy we spent on. It felt a patch on a sinking ship.

But I couldn’t see how to do anything better. None of us could even though we probably all knew that we were just pushing the problem more down the line.

But there were projects to deliver so the sense of action took over.

After an initial improvement, the situation did not evolve in a more sustainable way of working. Good intentions of reviewing code in time left the room once we turned on the pressure to deliver.

Never mistake the finger for the moon

After some time from that meeting, I was leading one of the two sub-teams and I was armed with all the best intentions to solve the miserable condition we were working in.

Struggles like the one I described before were just one of the many problems that were affecting the team. The misery induced by this situation pushed me deep into study-mode because I could not believe there wasn’t a better way.

This is where I started exploring the Theory of Constraints (TOC) and System Thinking principles. At first all that seemed so abstract but eventually it clicked.

Instead of providing me with answers, I ended up having even more questions. But this time they were good questions. The types that help you go deep into understanding reality and its subtleties.

Being a good inquirer is often seen as an expected quality for engineers but when it comes to these socio-technical aspects, asking questions can touch open nerves or challenge the way of working management has designed for the team (intentionally or not). This can lead you to become an annoyance for management. Learning to do it well is something that takes time to perfect. In the meantime, the risk on stepping on someone else’s toes is high, just be aware.

But I was loyal to the truth, not to management. Even better, I was loyal to my team which deserved better than that situation.

I realised we were looking at the finger when pointing to the moon. What we were trying to solve was high Work In Progress (WIP) and low collaboration.

Seeing the structures holding you down

It didn’t take much time to understand where to focus once I asked the right questions.

Almost each developer was working on a different projects or features. We had more projects and features than developers and upper management was under pressure. It was obvious that they had to parallelise the work. In all fairness, our management had to work inside a system where projects had to be started to calm the anxiety of higher management which tried to juggle several initiatives at the same time.

If you have any familiarity with Systems Thinking you are already aware that often the obvious solution is also the wrong one on a long term. On the other hand, counterintuitive solutions can be surprisingly effective.

In our case PRs were not reviewed because people had no incentives in looking at them because they often involved functionalities they were not familiar with or projects they did not have enough context of. Even when trying, it was hard to give feedback or approve something you don’t fully comprehend. One could also argue that doing code reviews is not efficient but unfortunately that was a company mandate that was hard to bypass.

When I looked at this it was crystal clear that without a drop in WIP no process could compensate for the limited cognitive capacity that people can have when multi-tasking.

Our desire to be productive was holding us down.

The solution was simple but required a leap of faith that in many corporation is hard to push: do less things at the same time. In other words, reduce WIP.

I started small by just focusing on the team I was leading and convinced management to make us work together on one project at a time and switching only after having achieved the desired next milestone.

The result? Looking at reviews became part of our routine because we needed to unblock each others and the code changes were more understandable because we all shared context of what we were building. Collaboration was high because it became a necessity for the job, not an impediment on the path to improve your own performance. Standups also became faster and more people were more involved.

One side effect of reducing WIP is that it forces you to prioritise. For real. Pick just one thing, the most important one, and work on it. That’s it.

We also delivered earlier than expected and we all felt more energised because we knew it was a team effort. It was a magical moment.

Even my manager was amazed by how such a small change had a tremendous effect. From that day, normal management practices seemed so naive and ineffective; a new perspective on a different way of working was born in me.

A different perspective on efficiency

Since then I have seen several other situations where similar problems were stemming from high WIP and my approach to it has been refined over the years but that meeting, with the over-engineered social process and the faces of resignation from developers, is still with me. I keep it in a drawer of my mind and look at it every time I find myself in a situation where all the energy is spent to design a process in order to control team’s behavior. It reminds me to look deeper, at the structures that hold this behavior in place.

Efficiency focus, as it is considered in most corporations, is now something that triggers me at many level as well. Often it involves changes to processes built on top of wrong assumptions and wrong metrics. Some of the common traits involve parallelising work and measuring and improving performances of individuals. Parallelisation as we saw does not bring necessarily an efficient system unless you are measuring vanity metrics (e.g. number of projects in progress).

On the obsession for measuring and improving individual performances I will have to dedicate another post because it is a concept that demonstrates lack of understanding of how complex system works. The focus for optimisation is actually about local optimisations which do not translate to a global optimisation on the system.

But again, this is material for another time.

One can see this as a more powerful version of current non-AI API1 based ecosystems that can manage specific problems and orchestrate different applications interacting with each other.

However, any human capability, in particular in the tech industry, produces waste. And AI is not immune to that.

One example of waste in the tech world is represented by the cryptocurrency phase, which led to a surge in electricity consumption. All to fuel mostly scams and money laundry operations.

All that electricity to mine useless coins and all the traffic generated by that data was waste for the overall society.

AI is not even remotely similar to the cryptocurrency. It has proven to have incredible potential to solve tedious tasks or enhance people’s capabilities while doing explorations in certain topics. But it is undeniable that with the increase of popularity came a hype that is currently causing many people and organizations to sprinkle AI functionalities everywhere hoping to see the advertised 10X (this is probably the lowest percentage advertised by most companies) performance improvements

Some of the AI costs are going down but the whole market is growing and propagating its effects. Improvements in algorithm efficiency appear to not be the most predominant factor in driving down costs (source epoch.ai). Hopefully this will change but for now, big tech companies are desperate for electricity to run more and more data centres to feed the growth that the AI introduction claims to bring to customers.

I argue that the race will bring its excess usage of AI agents where a simple, well thought and maintained non agentic API could save time (for users) and data traffic for the company. Similarly to when everything became an app in the early mobile period, even when this brought no value to end users but satisfied the need for a marketing stunt or enabled companies to harvest more data from users.

Eventually, I believe, a balance will be found but I wonder (as a thought exercise if for nothing else) how the world will be until the balance is found.

The reason for this “abuse” of AI agents can be explained by the fact that we are in a world of tech companies competing to gain space or upsell customers in:

• saturated markets

• monopolies

• monopsonies

In these situations consumers of tech products (e.g. apps) will have little or no choice on whether they these tools will be present in the software they are using. Users will be helpless because even if they run from one software, the next option most likely will suffer from the same level of enshittification due to the market dynamics. Imagine both iOS and Android introduce forcefully some AI feature that nobody likes, which OS will you use? You will need to chase a custom Android version but for the average consumer, is this a reasonable choice?

Let’s see an example

Imagine you use an app to read the news headlines and you have selected a set of newspapers you want to get news from in your personalized feed. Let’s imagine you even pay a subscription to this app to avoid having ads.

One day, someone in the product team responsible for the app thinks that instead users could ask the AI agent to get you the list of news you are interested in. They think this will give them more power and better access to info. Now users are stuck having to ask the agent every time to get the list of articles. Every time.

Is this an unrealistic scenario? Maybe. But not far from what’s already happening (see “Meta's AI-everywhere push raises hackles”).

The investors race fuels the enshittification

Unfortunately, with a powerful magnet for capital investments as the introduction of AI agents into existing processes, the temptation and the risk of leaning too much into the use of AI without understanding whether there is a problem that needs to be solved first is high. When companies are more focused on using a technology as opposed to solve users’ problem this can lead to solutions that don’t help anybody.

And that’s waste. Waste in the electricity to run AI model or to transfer the data as AI arguably uses more data than a simple non-AI API request that extracts data using conventional approaches (e.g. read a pre-calculated value stored in database). Waste in time of developers building and maintaining an overly complex system. Waste in time for users that every day they are forced to use a convoluted and over-engineered app their happiness is destroyed a bit.

Interestingly enough, OpenAI admits that even just using “please” and “thank you” incurs unnecessary costs for them due to usage of network and infrastructure. Looking at what is already happening we can predict that when AI will be deployed to several systems throughout the world, the systemic effects of using AI agents for everything will be significant. And so will be the effect of any wasteful activity these systems will cause.

Why is waste a risk for the introduction and development of AI applications? Because it risks compromising users’ trust and creating resistance even when AI is correctly introduced. Advocating for correct usage of AI is in the best interest of whoever is fully invested in the AI-wave that is taking over the tech world; the better we do at recognizing the actual problems that need AI, the steadier and more reliable the growth of the ecosystem will be.

Finding a balance will be necessary to create sustainable growth and benefits for everybody involved (companies AND users). Unfortunately, preventing this issue most likely will require fixing the economic and policy systems that allow these enshittification acts to flourish and persist.

And that’s not a coding problem so it is not so easy to fix.

“When people truly share a vision they are connected, bound together by a common aspiration”

This is an overview of the chapter about one of the five disciplines, “Shared Vision”. The amount of great content and wisdom summarised in a single chapter left me with a new perspective on how to gather a group behind a common vision. This article tries to share some of the key takeaways from it.

Most visions in today’s organizations unfortunately, at a closer look, are one group vision imposed on the rest. So why should people care? Will people believe the vision just because they have to?

There are visions and visions. Extrinsic visions are the ones focused on achieving something against an opponent (e.g. be the leader in the market). These are weak visions because they lose their powers once the goal is achieved, shifting the balance of innovation towards maintaining the status achieved. This results in the organization operating in a defensive position.

What leaders really need for continuous growth and development is an intrinsic vision, one that “uplifts people’s aspirations”.

The reason for this to be so important lies in this insight:

“Shared vision fosters risk taking and experimentation”

This is a desirable state for a truly innovation-inducing process. And it turns out that it also helps ensure commitment to the long-term goal of the business. One way to make sure people focus on the long-term goal is to make them “want to”, not “have to”. This can help create almost a self sustaining process.

It comes down to each individual “caring”, and “caring is personal”, writes Senge. This is important because the author also believes that shared visions emerge from personal visions.

Making people care fosters shared visions. Successful shared visions could lead to a mass of fully and truly committed people that in return keep the vision growing and expanding, helping the organization to grow and develop.

What can leaders do to create a shared vision?

The author suggests that leaders should communicate in a way that encourages everyone to share their vision so that everybody contributes to build and shape the shared vision. This starts by giving up the traditional approach of vision coming from the top or coming from an institutionalised planning process. These visions often do not build on personal visions and therefore do not create an environment where people get together and understand the common direction to take.

Another important aspect leadership should pay attention to is that “vision is not a solution to a problem”. If a vision is focused on a problem we have an extrinsic vision. Once the problem is solved the motivation in people declines because of a lack of a common aspiration that drives people’s efforts.

Unfortunately, when this happens, most managers make the situation worse by resorting to strategic planning processes in order to make people focus on new problems. But no planning can introduce the key personal aspect that a shared vision has.

“For those in leadership positions, what is most important is to remember that their visions are still personal visions. Just because they occupy a position of leadership does not mean that their personal vision is automatically “the organization’s vision”. When I hear leaders say “our vision” and I know they are really describing “my vision”, I recall Mark Twain’s words that the official “we” should be reserved for “kings and people with tapeworms”.”

How to build a Shared Vision?

The author acknowledges that it is not a glamorous process. Because it consists in listening to the organization and articulating a cohesive vision of what they are saying. The simple process of listening and collecting people’s feedback is often challenging enough in most organizations.

In order to build shared vision the author explores 3 important concepts:

• enrollment

• commitment

• compliance

Enrollment

The “buy-into-vision” approach, very popular in many organizations, creates the wrong attitude and, in most cases, leads to compliance masked as commitment. Enrollment actually involves free choice of becoming part of an initiative.

An enrolled person is someone who “will do whatever can be done within the power of the law“. A person that buys into it can at best offer fake compliance.

Once a person is enrolled, the next step is getting to commit to the vision. Committing to a vision means feeling fully responsible to make the vision come true.

Commitment

A truly committed person, one that has the personal vision aligned with the shared vision, has a natural and unmatched passion in navigating the challenges along the way. A committed person takes risks, challenges assumptions and experiments, driven purely by an energy fuelled by personal mastery (one of the other 5 disciplines) and aspiration to achieve the vision.

A company of truly committed people has an enormous competitive advantage when it comes to innovation because it has unlocked inner dynamics that can almost self-sustain the vision and guarantee useful experimentation to achieve the vision.

“Still today, many managers are justifiably wary of whether the energy released through commitment can be controlled and directed. So, we settle for compliance and content ourselves with moving people up the compliance ladder”

Unfortunately the “prevailing ways of management” as Deming described them still hold us back from achieving our personal and collective best work.

Compliance

In the author’s experience, 90% of organizations achieve only some level of compliance in their members. In the context of compliance, Senge warns about different levels and the impact that each has in the business activities.

The best type of compliance, called “Genuine Compliance”, is embodied by an employee that acts as a “good soldier”, sees the benefits of the vision and does everything expected. Then, on a lower level in the scale of desirability is:

• “Formal Compliance”a pretty good soldier

• “Grudging Compliance”, does not see the benefit of the vision. Still does what’s expected but openly disagrees

• “Noncompliance”, refuses to do what’s expected from them

• “Apathy”, neither for nor against the vision

Surprisingly the author admits that the “Genuine Compliance” is the most problematic because the person is committed to the team, not the vision. And it is often very difficult to distinguish it from true commitment. Still, a company of genuinely compliant people is far more productive and effective than most organizations.

Visions, after exploring these aspects, do not appear as marketing stunts or PR materials to excite shareholders, but become a foundational stone to build an organization that can develop, grow and sustain its growth.

The Internet has allowed people to share stories more easily around different companies’ visions and how they operate to achieve them. The picture that is in front of our eyes says that most organizations get what they deserve. An ocean of compliant people that do not share the same passion as leadership and do not see the value of investing their full potential to reach a vision they don’t agree with or share.

When companies complain that people lack the passion at work, they are often describing in great detail a leadership failure to create and communicate a truly shared vision.

Image prompt ChatGPT: Create an image about discovering our thinking in times of AI. Do not write any text in the image. It is an uplifting image of what critical thinking, knowledge and AI hallucinations evoke in you

AI can make some tedious tasks faster by automating the analysis and generation of content, providing the output in our most preferred media (text, audio, video). People use AI in their work tasks, saving a great amount of time and even gaining access to capabilities that were previously reserved to domain experts. This brings great benefits and has generated a reinforcing loop in offloading more and more tasks to AI.

With such a high level of automation it is easier and easier to offload more and more of our mental activity to the AI, giving trust in its guidance. But AI hallucinations have proven to be harder to recognise than we think.

With the rise of the Internet came a flood of data, misinformation and fake news. This is only one side of it but it is not one to be ignored. Relying on the Internet has given a tremendous power to people but these types of problems have caused huge suffering, the quantity and quality of which we are still trying to figure out. And maybe we never will because we will have to keep up with the present and more persisting issues.

Now we are opening the door of our digital spaces to these tools that all, more or less, are at least suffering from transparency issues over data used for training and questionable handling of users’ data.

They are smart tools, claim the AI enthusiasts. It is undeniable they are useful. However, the difference between a smart software and a stupidly smart one becomes blurred or harder to detect in AI systems. When these AI tools fail, they fail with confidence and investigating their thinking sometimes is harder than with people (when AI tools actually allow themselves to be investigated in their thinking).

Confidence can be persuasive for humans, leading to misplaced trust in AI capabilities and AI results at face value. This is nothing new if we recall the incidents of people believing the GPS more than what they see.

What kind of thinking is necessary for people now in the light of these new tools gaining increased popularity? If AI cannot be trusted but cannot be ignored, what should be the approach to articulate your own thinking around what AI tools tell you?

Questioning AI generated answers pushes human capabilities on a path of constant analysis, detection and exploration of issues. Basically it pushes people to adopt many of the practices involved in critical thinking.

Critical thinking is now, more than ever before, a required skill in order to construct anything of a relevant level of complexity combining these newly discovered capabilities.

Considering the strong imbalance of computational power between a person and an AI program, it is necessary to leverage these AI tools in order to be effective and efficient in controlling and reviewing the AI generated content itself. But in the end, humans need to acquire the ability to manage and verify the knowledge AI provides.

Despite all the training data, a human decision is necessary to properly handle AI abilities. This means the human should define what is right. But how can we do that if we can’t keep up with how AI thinks? Our thinking must embrace new ways to handle these new flows of information, these new interactions.

It is ironic that we train these tools on tons of data for them to have to be retrained again by us, right when we think they are smart already.

You never stop learning, indeed.

From Greek διάλογος (dialogos)

• διά- (dia) = through, across, or between

• λόγος (logos) = speech, discourse, reason, or word

Essentially a flow of words.

“In practical terms, this means a group of people speaking together not to win an argument, but to uncover deeper truths — suspending judgment, listening actively, and surfacing hidden assumptions together.”

Dialogue feels natural, yet it is surprisingly difficult to practice consistently and intentionally. This challenge arises from the collective nature of dialogue which requires coordinating multiple minds and that adds complexity.

Entering a dialogue requires accepting certain ground rules. I’ve found that it can be useful to start from the Basic Assumption stated in this lesson from the “Introduction to System Dynamics” lesson:

“We believe that everyone in this class is intelligent, capable, cares about doing their best and wants to learn.

This Basic Assumption is the foundation for proper dialogue among people. Dialogue requires surfacing assumptions and acknowledging knowledge gaps in the open so that everybody can learn from these and build a better understanding on top of it. A class is obviously the standard place where the goal of the group is learning.

Purpose

Dialogue is a critical activity to enable systems thinking by allowing to see each other's mental models without having to defend any of them but engage in a sharing of ideas that allows to do self introspection (evaluate the ways each one of us sees the reality) and a collective introspection of what are the actual and shared mental models in reality (what the group believes it’s the reality).

Seeing and exposing mental models helps reveal hidden or unexpressed assumptions that hide untapped potential. The gaps in collective knowledge that nobody publicly addresses but affect everybody.

Kind of like a closed door you never dared to open. Where will it take?

Dialogue, talking with each other, in the right context is the best solution. It doesn’t mean that dialogue is the only way of communication but the organization should learn to actively engage and leverage the power of dialogue, especially in a creative process.

Psychological Safety

Guaranteeing the Basic Assumption requires clearly a high level of psychological safety in the group. Without it, no proper dialogue can occur because there will be certain assumptions or decisions not shared explicitly and that cannot be challenged, limiting the systemic impact of any decision originated from the dialogue.

An organization that is based on such an assumption allows each individual to be at their best, supporting and developing personal mastery of each individual and the organization’s mastery as a whole.

Imagine starting your meetings with this as a core shared assumption. Then a dialogue is the only reasonable way of communicating between peers. For a world to work like this it may take centuries to happen, but an organization could have this in a shorter time frame if the energy is applied in the right places.

In order to achieve such a level of collaboration, it helps to have the right leverage. A shared and clear vision could fuel such organizational change. A vision could be a starting point for a change that puts dialogue at the centre of the organization’s process.

Whatever the leverage is, maintaining (or just achieving) good levels of dialogue represents a big change. It’s then a muscle that must be trained, carefully and constantly. It is not innate but must be cultivated.

It is a commitment to personal and collective mastery, an intimate human desire to achieve the sense of purposefulness.

Dialogue and AI: The Next Frontier?

Is dialogue an oral thing only? Predominantly. I wouldn’t know how to reproduce it in a written way; the closest would be a text chat. But I don’t know how much the delay in response influences the flow.

One could even imagine this with an AI agent. But then if we talk to an AI, will the knowledge grow for both the human and the AI at the end of the dialogue? Or will the AI forget this? Maybe it grows (stored information) but will it develop? By developing I mean, will it affect the future reasoning of the AI similarly to how that dialogue could shape the future mental models of the human?

An AI that does not gain insights from conversation loses one key aspect. Learning happens when there is the change in our current understanding of reality, when we update our mental models.

An AI that can dialogue could be critical in a learning organization since it enables continuous development and definition of the mental models controlling the organization’s behavior and therefore drive effective and sustainable changes.

Looking at the whole

Any development of these AI capabilities must be considered in terms of the organization’s development. We must create a sustainable development with the reference of the system composed of:

• people

• finance

• environment (includes AI)

In particular it remains important to guarantee people’s development even in times of AI, if nothing else to mitigate the damage from AI hallucinations or fill in contextual information AI agents may not be able to access or understand. This contextual information may be the key to discover untapped potential.

If AI does not learn to challenge assumptions, people will have to learn to do it and have a way to navigate the complexity and large amount of conflicting information.

References

I’ve found the book “The Fifth Discipline” to be an eye opener for me on how much untapped potential there is in most organizations and how learning to leverage it by applying systems thinking methodologies could untap unexpected capabilities in an organization. The practice of dialogue is one of the many the book goes into great detail articulating.

Psychological safety: the belief that one can speak up without risk of punishment or humiliation

In her book “The fearless organization” Amy C. Edmondson provides an outstanding and eye opening analysis of the different elements involved in creating environments where the removal of fear can allow employees to contribute freely and impactfully to the organization’s goal.

Fear is the 8th of 14th Deming’s principles to improve management effectiveness:

Drive out fear, so that everyone may work effectively for the company.

Eliminating such fear and maintaining a system where respect and mutual understanding is guaranteed, enables a profound change in the way people work.

Improvements of the overall systems become easier because members of the organization can contribute, with their insights, into the improvements of the system they live in. As a result, people end up improving the overall system effectiveness by improving at the same time their working situation.

It creates a pervasive quality that influences the whole process and lifts all its members.

The organization will not be immune to failure, the only difference is that these failures are because of a wrong assumption when modelling the problem and solution, not because of naive reasoning.

But luckily a wrong assumption is the base for a more correct understanding of the world.

Intelligent failures, in a learning organization, are celebrated and considered critical for its growth. Failure has to be accepted if obtained based on an intelligent strategy that reveals unexpected flaws in our understanding of our reality.

If you think about it, science is fundamentally based on the assumptions of being wrong or proving somebody wrong following a methodical, repeatable, and intelligent process. Unfortunately when science was applied to management it generated “Taylorism” (Scientific Management) which has long been abandoned but left a profound impact in how management is still taught and believed nowadays.

Because of the social aspect of the system (the organization), a psychological element is necessary for the organization to perform effectively. This element represents the underlying agreement on the fact that the human mind and human behavior can impact tremendously the effectiveness of an organization.

Enhancing the organization’s members’ impact can be done by creating such space so that the overall output of the system is bigger than the sum of the parts.

An environment with such qualities allows members to apply improvements enhanced by systems thinking which has the precondition that members must have a chance to learn, experiment and fail in order to improve the organization’s process.

Only then effective and bold changes be made and experiments run because they are supported by the environment and collectively improved.

Takeaway:

For an organization to constantly learn it is necessary to remove, in its members, the fear in speaking up due to possible retaliation. As necessary as it is for many other aspects (transparency purposes, auditing, legal compliance, safety), removing fear from the company and supporting an environment with psychological safety is surprisingly critical for a company to thrive its business because it allows to set in place practices based on a systemic view of the organization’s process.

See also:

What Psychological Safety Looks Like in a Hybrid Workplace by Amy C. Edmondson and Mark Mortensen

This means that:

1. a system (the whole) has essential properties that none of its parts has

2. broken into parts, a system loses all its essential properties

These considerations have a valuable implication:

A system cannot be understood only through analysis, because analysis requires breaking the system apart in order to understand each element separately.

Analysis is necessary but not sufficient in creating a comprehensive understanding of the system. Understanding each part working does not explain how the whole operates together. The same way knowing how a car works does not make you capable of driving it.

The aggregation of parts back together is called Synthetic Thinking: it defines HOW the parts interact with each other inside the system.

But…

It only explains how, NOT WHY the system works that way.

Russell Ackoff tells us that the WHY a system is that way is almost never inside the system but it can be found in the environment where the system operates in.

His example was: consider cars for the UK market with the steering wheel on the right side. If you take the car apart you won’t figure out why it is on the right. In order to know why, one has to understand where the car (system) operates in and political and legal rules that govern it.

To summarise:

ANALYSIS brings KNOWLEDGE but not understanding.

SYNTHETIC THINKING brings UNDERSTANDING.

Now combining the two and considering the environment the system and us live in, we can obtain a broader perspective, bigger than the one provided by the simple sum of the parts considered separately. 1

ANALYSIS + SYNTHETIC THINKING + WHY2 = SYSTEMS THINKING + LO3

What do we obtain?

An understanding of how the system operates as a whole. The holistic view.

This view of White Lake (B.C. Canada), was for me inspiring to appreciate how complex systems can act naturally in a bigger system present in the environment. And in that system I was included too. I realise now with noticeable delay.

We are in the environment. We observe and influence. But anyway we need to be there.

I had to learn to act naturally. I decided to learn to think naturally first.

Admiring the landscape, beautiful assembly of elements, gently and naturally melted together. Such a composition generated in me, viewer, a deep and profound perception of how the environment has all these elements interacting; and when these interactions are painted of the quality without name (see “The timeless ways of building”), then all appears as natural.

My wonder at such beauty left me a little note on the wall of my mind.

That’s my awareness. Be aware.

Of the system in the environment you live or work. Be aware you are, oftentimes, in the system you try to change.

All the uncovered perceptions are learning for a systemic understanding. Here there will be some of the thinking around a systemic understanding of context like software development, AI applications in real life, ethics practices and, honestly anything that piques my interest from a systemic understanding point of view.

Writing is a form of processing and learning in this process. Like everybody, I need to find my learnings so I write to clarify my thoughts. 

It's asystemic in the way it works.