In many organizations, “we need more control” sounds reasonable. Something goes wrong, a deviation is reported, or a leader is questioned by the board – and the response becomes: add more control.

The problem is that control rarely stops where it started. New forms, extra approvals, additional reporting and local checklists appear. What was meant to create security can end up creating friction and frustration.

When the focus on control grows, many actors start their own local control initiatives. Units, teams or individuals add their own checks “just to be sure”. This often happens without coordination, and can easily lead to unnecessary or even harmful control. The result is parallel controls, duplicated work and a patchwork of measures no one has the full overview of.

Unnecessary control shows up as time spent on reporting, documenting and signing off without any real effect on outcomes. Harmful control shows up when routines and approvals slow down the work, reduce flexibility and undermine professional judgment. Employees may feel they spend more time documenting their work than doing it, while leaders drown in reports that do not improve decisions.

To avoid this, it is important to have a clear strategy for where and when control should be applied. Control should not spread by default. Before new measures are introduced, someone should always ask: What are we trying to prevent or achieve? Which concrete risk are we addressing? How will this be experienced in practice? How will we know if it has an effect?

Control should be used where it actually makes a difference. That means prioritizing areas where the risk or consequences of errors are high, where there are legal or regulatory requirements, or where there is a history of recurring deviations. Not all areas need the same level of control, and overcontrol can be just as damaging as too little control. A simple principle can be: as little as possible, as much as necessary.

It also matters who performs the control and how it is done. Control should be carried out by competent actors and supported by good systems. Those who control need to understand the subject matter and the processes they are looking at. Systems and routines should be simple, understandable and integrated into everyday work, not added on top as separate layers that no one believes in.

Without this, the control regime itself can come out of control. You get ever more requirements, more data and more reporting, without a clear sense of what is useful. The organization slows down, frustration rises, and trust is weakened.

To keep control under control, someone must take responsibility for the overall picture. That includes regularly reviewing existing controls, removing or simplifying what no longer gives value, and involving those who are actually being controlled when new measures are designed. Control should be a tool that supports good work and sound decisions – not a system that runs away from the people it was meant to help.

Most of us spend our days dealing with problems. Something breaks, a delivery is late, a deadline slips, a system crashes. We jump in, fix it, and move on. Another way to relate to problems is to work so they never show up in the first place.

This raises a simple question: what interest drives most agents, whether human or machine? Is it mainly about solving the problems that appear, or about preventing them from happening at all?

In practice, most people, teams, and agents focus on solving problems when they arise. It is visible, concrete, and easy to point to. You can say: “Here was the problem; here is what I did; here is the result.” The work is tangible and easy to recognize. This kind of problem-solving often creates heroes: the person who steps in when something goes wrong and fixes it.

Preventing problems is different. It is about noticing risks in advance, planning carefully, building good routines, and improving systems so that certain problems simply never occur. When prevention works, nothing dramatic happens. There is no crisis, no story, and usually no visible “before and after.” Because of that, very few people see the problems that never appeared. Preventive work is often taken for granted or not even noticed.

Ideally, we would prioritize both: solve the problems that arise and work to prevent them in the future. After fixing something, we would ask: “What can we change so this does not happen again?” Over time, prevention would reduce the number of issues that require urgent attention. But when an actor has to choose—because there is limited time, money, or energy—solving visible problems usually wins. It feels urgent. It is easier to justify. It is easier to measure.

This creates a pattern. Reacting to problems becomes the default. People get used to firefighting, and the organization learns to depend on crisis work instead of steady improvement. The better someone is at prevention, the less obvious their contribution becomes, making it even harder to justify preventive work when pressure increases.

A more sustainable approach is to make room for both. Keep solving the problems that arise, but also set aside time and attention for preventing new ones. Make preventive work a conscious part of the job, not just something you do “if there is time.” And when something does not go wrong—when a project runs smoothly or a system stays stable—recognize that this is often the result of invisible, preventive effort.

Solving problems is visible. Preventing them is mostly invisible. Both matter. The challenge is to resist the pull toward only what can be seen and praised, and to also value the problems that never have to be solved.

We were supposed to create a mosaic. Not just any mosaic, but one built from pieces with different shapes. The idea was to show that you can create something fantastically beautiful out of diversity and variation. The strength of the mosaic was that things were not alike. Irregularity and difference were the whole point.

To make this possible, we created a system for producing the pieces of the mosaic. The goal was practical: we needed a way to produce enough pieces to actually build the mosaic. Over time, this system was streamlined and optimized. The main measure of success became how many pieces we could produce.

The way we achieved this was by making all the pieces the same. Same shape, same form, same structure. From the perspective of efficiency, this made perfect sense: identical pieces are easier and faster to produce. But from the perspective of the original idea, it quietly destroyed what we were trying to do. We wanted a mosaic that drew its beauty and strength from difference, and we ended up with a system designed for sameness.

At some point, we noticed that the result did not match the original vision. So we tried to fix it in a simple way: we painted the pieces in slightly different colors. That gave us some variation, but only on the surface. The pieces still had the same shape; they only looked different because of the paint. The diversity had become cosmetic instead of structural.

Developers now use language model–based tools for software development. These tools can write, refactor, and explain code. They come with clear and obvious advantages: development is faster, boilerplate disappears, and it is easier to get from idea to working code.

If that is true, it feels natural to expect that the amount and quality of software should have gone up. The tools and apps we use should have become better and more capable. We should see new tools in areas where we did not have any before. In general, there should simply be more good software.

But do we actually experience that?

When we look at the apps and tools we use every day, many of them feel much the same as a few years ago. Some have gained “smart” features and assistants. A few things are smoother or slightly more automated. But we do not see a clear wave of fundamentally better tools, or a flood of new kinds of software in areas that were previously untouched.

Something seems to block the translation from better development tools to noticeably better products. Part of the explanation is that writing code has never been the only hard part. Understanding users, deciding what to build, designing something simple enough to use, dealing with legacy systems and regulations — none of that disappears just because code is easier to generate.

Incentives also matter. Many companies optimize for engagement, lock-in, and short‑term metrics, not for maximum quality or radically better user experience. Extra development capacity can end up in internal projects, experiments, and incremental changes, instead of visible improvements to the tools we rely on.

This does not mean language models make no difference. For developers, a lot has changed: faster prototyping, easier learning, less time spent on repetitive tasks. There are also behind‑the‑scenes improvements in infrastructure and internal tools that users rarely see directly.

If we really used this new capability to its full potential, we might expect more obvious results: simpler and more reliable everyday apps, more tools for niche workflows and small professions, more software adapted to specific languages, regulations, and local needs.

The question “Where is the improved software?” is therefore less about the tools themselves and more about what we choose to build with them. The technical ability to create more good software is increasingly there. Whether we actually get that software depends on priorities, incentives, and the willingness to aim for genuinely better tools, not just more code.

When an agent needs to make a decision, it considers the possible actions against its goal. Each option is evaluated: does this move us toward the goal, and is it good enough compared to some minimum requirement or threshold?

The Default Do Nothing (DDN) pattern says that if none of the available decisions can be judged as good enough, the agent should default to doing nothing. Instead of forcing a low-quality or risky choice, the agent deliberately chooses not to act.

Doing nothing is treated as a real, explicit decision. The agent has evaluated its options and concluded: “None of these actions meet the required standard. Therefore, I will not act right now.” This is not a failure or an error, but a strategy.

When DDN is triggered, the agent waits to see if conditions change. That might mean more information becomes available, the situation changes, or new options appear. The idea is that by postponing action, a better decision may become possible later.

If conditions do not change, the agent effectively commits to having done nothing. In that case it is betting that doing nothing was still the best available choice compared to the poor alternatives. In many situations, especially where the risk of a bad decision is high, inaction can be better than a wrong or unsafe action.

The core of the DDN pattern is simple:
when no option can be evaluated as good enough relative to the goal, default to doing nothing, wait for possible changes in the situation, and accept that sometimes the least harmful and most rational decision is not to act at all.

Many people struggle to change a process, even when they can see it will not lead to a good outcome. Instead of adjusting, they hold tightly to the process details and argue that sticking to the process is more important than the result. That raises a simple question: is a process actually good if it leads to bad results?

One reason we cling to processes is comfort. A process tells us what to do next. If something goes wrong, we can say, “At least I followed the steps.” In some organizations, this is even rewarded. You can fail as long as you did things “by the book,” and you can be criticized for breaking the process even if the outcome was better. Over time, this teaches people to defend the process instead of improving the result.

Ego and identity also play a role. The process might be “our way of doing things” or something we designed ourselves. Admitting that it doesn’t work can feel like admitting we were wrong. To avoid that, we double down: we argue that following the process is what really matters, even if the outcome is clearly poor.

This has real costs. Teams waste time and resources continuing with a process that everyone quietly knows is not working. Opportunities are missed because better ideas don’t fit the existing way of doing things. “We followed the process” becomes an excuse, not a learning moment. When the process becomes a shield, reflection and improvement stop.

If we are honest, a good process is not one that is detailed or strict. A good process is one that increases the chances of getting the results we actually care about. If a process repeatedly leads to bad outcomes, it is not a good process, no matter how official, familiar, or well-documented it is.

There are some warning signs that a process is failing. Outcomes are consistently worse than expected. People complain informally that “this is pointless, but we have to do it.” Most discussions focus on whether the steps were followed, instead of whether they made sense or helped. In moments like this, it helps to ask simple questions: what result are we trying to achieve, and is this still the best way to get there, given what we know now?

Shifting from process-first to outcome-first does not mean chaos. It means treating process as a tool, not a belief system. You can define in advance when you will review and possibly change your approach: if a certain result has not happened by a certain time, you revisit the process. You can make it normal for someone on the team to challenge the way you work and suggest changes. And you can reward people not just for following the process, but for improving it when reality shows it is not working.

In the end, the core idea is simple: a process that leads to bad results is not a good process. The goal is not to worship the process, but to reach meaningful outcomes. Next time you are tempted to defend a poor result with “but we followed the process,” stop and ask: what needs to change in our process so we don’t end up here again?

Many people use a language model as a tool that “writes things for you”: emails, code, summaries, blog posts. In that way of working, the model is a generator. You ask it to produce specific content for direct use, and the output is the product.

Used as a generator, a language model creates text, code, or summaries that you can use more or less as they are. You might ask it to draft an email, write a short article, generate a function in Python, or summarize a long document into a few bullet points. The goal is fast production of specific content, where you mainly edit and polish what the model gives you.

There is another way to use these tools: as a knowledge system. Here, you are not asking the model to deliver the final product. Instead, you are using it to find information, explore possibilities, learn, and think. The focus is on working with knowledge rather than generating finished text.

As a knowledge system, a language model can help you find relevant information on a topic, highlight options you might not have considered, and point you to potential opportunities. You can use it to learn something new by asking for explanations, examples, and comparisons, and by letting it guide you step by step through complex material. You can also use it to work with and improve what you are already doing: ask for feedback on your draft, suggestions for better structure, or ways to clarify your arguments or design.

In this knowledge mode, the final product is not generated by the model. You stay the author and decision-maker. The model supports your thinking and helps you refine your work, but it does not replace it. The main value is in discovery, understanding, and improvement, not in ready-made output.

Both ways of using a language model are useful. As a generator, it helps you produce concrete content quickly. As a knowledge system, it helps you find information, see new possibilities, learn, work with knowledge, and improve what you are already doing—while keeping the actual product in your own hands.

When something goes wrong, we usually fix what is broken right now and move on. The bug is patched, the incident is closed, the meeting is rescheduled. But many errors are caused by other, earlier errors. What we see is often just a symptom.

Behind the visible problem there is often a root cause—the original error. This is the first actionable mistake in the chain of events. It might be a decision, a missing check, a wrong assumption, or something we forgot to do. If we find and fix that original error, we often solve many problems at once and prevent new ones from appearing.

In practice, we often don’t do this. Time pressure, habits, and routines push us to focus on the immediate problem. We close the ticket and move on to the next task. As a result, the same types of errors keep coming back in slightly different forms, and we end up firefighting instead of improving.

The original error is also where we can learn the most and get better. It is the point in the chain where we can ask: what should we have done differently? Which assumption was wrong? What was missing in our way of working? This gives a real basis for change and improvement, instead of vague ideas like “we should be more careful”.

Original error analysis is a simple method for doing this. You start by describing the visible error clearly: what happened, when, and who or what was affected. Then you repeatedly ask “what caused this?” until you reach the earliest point where a realistic action could have prevented the problem. That point is a good candidate for the original error.

It is important to check that this is actually an original error, and not just another symptom. A useful test is: if we fix this, will it significantly reduce the chance of similar errors in the future? If the answer is yes, you have probably gone deep enough. You do not need to go all the way to abstract causes you cannot change.

Once you have identified the original error, you can decide what to change. That might be a small adjustment to a process, clearer communication, a checklist, a review step, or some simple automation. The goal is to change the conditions that allowed the original error to happen, so that you avoid a whole class of future errors.

This way of thinking is also useful for “wicked problems” – complex, messy problems that are hard to define and hard to solve. You may not find a single clean root cause, but original error analysis can still help you see earlier decisions and structures that shaped the situation, and where you still have room to act.

Original error analysis works best when it becomes a habit. After something goes wrong, take a few minutes to ask: what was the first mistake in this chain? What can we change so this does not happen again? Over time, this shifts focus from firefighting to learning and improvement, and helps prevent many errors from occurring in the first place.

Some initiatives, projects, solutions, businesses, products, and markets are by their nature built so that only one or a few can win. The upside can be huge: money, status, visibility. But the downside and the risk are just as large. For most people who join, the most likely outcome is to lose almost everything they put in: time, energy, and sometimes money.

If you want to succeed in a way where you are almost certain to get something back for your effort, you need to think about what kind of “game” you are entering. If you want to be able to live with not being the best, but simply being good enough, then you need to avoid games that only reward the single winner.

That means choosing arenas where more than one person, company, or product can do well at the same time. Places where competence, reliability, and steady work are enough to give you a decent result, even if you never become number one.

The good news is that most activities in work and business are like this. They are not glamorous. They are often normal, common, even a bit boring. But they are also safer. You don’t have to crush everyone else to have a good outcome. You can do solid work, be good enough, and still be rewarded.

There is nothing wrong with aiming high or trying something ambitious. But doing it blindly in a winner-takes-all setting means you are accepting a very high chance of “all or nothing.” Before you commit to a path, ask yourself whether you are entering a game where only a few can win, and whether that is actually what you want.

Most of the time, especially if you care about stability and a livable life, it makes more sense to choose the steady, common, “boring” games. They may not look as exciting from the outside, but they let you build something that lasts, without needing to win it all.

“Let’s build an agent for that.”

That’s a common reaction to almost any problem right now. If there’s a repetitive task, someone suggests wrapping a language model in an “agent” and letting it handle everything end to end.

But an agent is only one option. You can build an agent to automate a task. You can build a normal program. Or you can simply add the functionality to the tools people already use.

The real question is: when should you build an agent, when should you build a regular program, and when should you just extend the existing tool?

Imagine a simple, old-fashioned proofreading workflow. You sit and write a document in a basic text editor. There is no built-in spellcheck, no grammar help, no automatic feedback. When the document is ready to go to print, you print it out on paper. You send this printout to a colleague for proofreading. The colleague reads the document, underlines spelling mistakes, marks typos and other errors, and writes corrections in the margins. Then you get the paper back and sit down at your computer again. You go through the marked-up pages and manually correct the original document in the text editor.

This is a separate, clearly defined step: first you write, then you print, then someone else proofreads, then you correct.

A naive “agent” approach would be to replace the colleague with a language model agent, but keep the rest of the workflow more or less the same. You still write in the same simple text editor. When you are done, you print the document or export it to a file. You send this to a system that scans or reads the document. The agent runs through the text, finds spelling mistakes and other errors, and produces a new, corrected version, maybe with underlines and suggested fixes. You then print or download this corrected version and use it to update your original document.

On paper, this sounds modern: the human colleague is replaced with an automated agent. In reality, it keeps a lot of unnecessary steps. You still print or export. You still send the document somewhere else. You still jump between different tools and representations of the same text. You have built a separate system around the work instead of improving the place where the work actually happens: the text editor.

The smarter solution is the one the world discovered quite quickly for text processing: build spellcheck into the editor itself. Instead of a separate proofreading step, the editor underlines spelling mistakes as you type. You get suggestions directly in the tool where you write. You fix errors immediately, without printing, scanning, or sending anything to a colleague or an agent. Spellcheck is not its own system; it is part of the work tool.

This is the core idea: not everything that can be automated needs an agent. Often, the right move is to bring the functionality into the tool where the user already works, instead of wrapping the old workflow in something that looks clever from the outside.

You might choose an agent when the task really does span multiple tools and systems over time, and there is no obvious main place to put the functionality. You might choose a normal program when it is a separate job with clear input and output. But when the task is tightly connected to what the user is already doing in one tool—like proofreading while writing—the natural place for that functionality is inside that tool, as part of the workflow, not as a separate agent.