When I led mobile engineering teams, I started my day in Mixpanel and Crashlytics. Happy paths, UX glitches, conversions, error codes. I wanted to know everything.

Today, leading Platform Engineering, I practically live in Coralogix, Grafana, and a few hand-coded dashboards/status pages. My 50-widgets god views track every error 5xx, slow endpoint and web vitals degradation across hundreds of microservices and microfrontends our organization manages.

I also weaponized AI to generate incredibly detailed, multi-page incident reports for every bug I found. I was incredibly proud of the observability machine I’d built.

The problem? Engineers completely ignored it. This was super annoying - I can point out errors 500/503, not touched for years, even though I escalated that on all angles. I provided everything - logs, stack traces, service details, volume of the issue. 2 pages elaborate with 4 Grafana widgets pointing to a part issue.

I thought I was helping, but in reality, I was just shoveling more cognitive overload onto product engineering teams that were already drowning in a product super growth phase.

Took me some time to realize my failure wasn’t technical—it was deeply psychological. I fell into today’s trap of abundant content generation: I assumed the answer was to build more.

The Additive Bias

In April 2021, a study published in Nature proved exactly how deep this blind spot goes. Researchers gave participants a Lego bridge with uneven support pillars and asked them to stabilize it.

In the observational studies, 78% chose to add elements, while only 20% chose to subtract. Even when subtraction was the objectively superior and faster solution, people still defaulted to adding unless they were explicitly reminded that taking things away was an option.

The study proved that when asked to improve a situation, our brains default to searching for elements to add. We systematically overlook subtractive changes.

In the age of AI, where the marginal cost of creating code, text, and components has dropped to zero, this Additive Bias is dangerous.

We can generate endless reports, connect dozens of APIs, and bolt on new dashboard widgets simply because we can. Yet the true cost is not creation, but consumption. I covered it here:

The Three Mile Island Control Room

To understand what happens when the Additive Bias goes unchecked, look at the Three Mile Island nuclear accident.

As Cliff Kuang points out in his book User Friendly (a must-read if you want to understand UX better!), the 1979 disaster wasn’t caused by incompetent operators; it was a catastrophic failure of information architecture.

The control room was a masterpiece of over-creation. Hundreds of warning lights and alarms. When the core began to fail, everything lit up and buzzed simultaneously. The operators were completely paralyzed by cognitive overload.

Okay, now the confession: is there anyone reading here who doesn’t have such A Three Mile Island control panel in your observability dashboards? Mine happen to be depressingly red almost all the time 😅, even though the product seems to be working well.

And here’s the thing - when every metric is screaming for attention on a massive dashboard, the signal is entirely lost. My dashboards didn’t make my engineers’ lives easier; they just added cognitive weight.

The AI Trap and Hick’s Law

This year, I switched from dashboards to AI-generated incident reports, convinced I was fixing the problem. I have a few of the agentic flows digging through different CLIs.

Example: I have a morning-brief flow that fetches last 24hrs of alerts and spans a few subagents, that run: a) Coralogix CLI to fetch alerts, logs, and traces; b) cloud infra review of terragrunt files (from alert tresholds to identifying owners of the services); c) Github CLI to fetch the source code of affected groups of services.

If something catches my attention, there is a more detailed flow with the same CLIs for triaging the particular alert → tracking the root cause, identifying blast radius or corelating issues with the latest Pull Requests / Deploys.

For each I get the comprehensive summaries of why things were breaking. It’s very detailes (e.g. it brings the list of all CLI calls, so I can reproduce the entire reasoning process). But it is also massive reading block.

If the Nature study explains why we add, Hick’s Law explains exactly what it costs us when we do. Formulated in the 1950s, the law mathematically proves that the time it takes for a person to make a decision increases logarithmically with the number and complexity of choices.

By handing a developer a three-page AI summary, I hadn’t solved their problem.

The cognitive overload problem isn’t something new. There is also another framework NASA-TLX (Task Load Index)—the framework used to measure cognitive strain on astronauts. Looking my reports through the TLX lenses, I’m pretty sure I had actually spiked engineers’ Mental Demand and Frustration Level.

They now had to parse the AI’s logic, verify the evidence, and figure out the fix. The AI had successfully generated content, but it hadn’t reduced human confusion.

Tesler’s Law and the Agentic Shift

The breakthrough came when I stopped trying to generate insights and started focusing delivering value. This is with Tesler’s Law in mind.

Coined by Larry Tesler at Xerox PARC, the law states that every system has an inherent amount of irreducible complexity. You cannot magically make it vanish; you can only shift who has to deal with it.

If you want to simplify the user’s experience, the engineering team (or in this case, the AI agent) has to absorb the complexity.

Today, my agentic flow doesn’t write reports. It gathers the telemetry, correlates the logs, and actually attempts to reproduce the bug—writing and executing simple Node scripts to simulate the failing sequence. Then, it does the most important thing: it synthesizes all of that into a single executive summary attached to a ready-to-merge Pull Request.

I shifted the complexity to the agent, reducing the engineer’s interface down to a single, binary decision: Approve or Reject.

For those who want to verify the agent’s work, there is an appendix attached to the PR containing the raw CLI commands, logs, and prompts. The complex machinery is there if you need it, but it is hidden from the main view.

Less, But Better

Long before software interfaces existed, industrial designers fought this exact battle against over-creation. The functionalist principles of the mid-20th century—championed by Dieter Rams at Braun—serve as a masterclass for modern digital makers.

His core philosophy, Weniger, aber besser (”Less, but better”), is the physical embodiment of Tesler’s Law. Look at Rams’ design for the Braun ET66 calculator. It doesn’t have extra scientific functions exposed on the front. Rams absorbed the complexity of the internal electronics so the user could experience pure utility.

Good design is unnoticeable. It shouldn’t scream for attention with flashy, over-engineered components or massive AI-generated reports. It should act as a quiet, highly efficient tool.

In the age of AI, our major job is to edit, reduce, and simplify. Complexity is not a feature.

Supplemental Reads

• Tesler’s Law of Communication

• The “User-Friendly” Engineering Framework

• The End of the Traditional Coder

As a designer or engineer, you face a choice: you can either force the user to navigate a complicated interface, or you can do the hard, invisible work behind the scenes to make the experience seamless.

Lately, I ran some thought experiments on what Tesler’s Law can teach us about effective communication, especially with your stakeholders and executives.

Because esp. now, in the abundance of generated content, too many leaders are pushing the complexity onto their CTOs and VPs.

Exposing the Wiring

My thoughts brought me back to 2019, my week in Silicon Valley. Me heading to Google I/O. Instead of enjoying the 7km walk in a new place, I wrote another email-essay to my CEO…

That day our mobile app was taken down from the Play Store due to a policy violation regarding private APIs. The fix itself was trivial: bump the SDK, use the newly exposed public API, and inform stakeholders about a temporary gap in processed data. It was perhaps one hour of work.

Yet, I wrote an essay-long deliberation to the CEO. I detailed the wrong architectural decision we had made a year prior. I explained how Google’s policies had shifted over time. I outlined how the Play Store linters now flag this specific violation. I added my personal thought process, interesting alternative ideas, and technical nuances.

I was trying to show up.

I wanted the executives to understand every single detail, step into my shoes, and reproduce the problem step by step. Deep down, I also wanted to dilute my responsibility for the mistake by drowning it in context, proving my professionalism by showing exactly how much I knew about the system that had just failed.

The CEO responded to my two-page essay with a single line:

“Mirek, you write too long emails.”

I was stunned. Did he really not care that our only app was missing from the store?

It took time to realize that → He wasn’t ignoring the crisis; he was rejecting the cognitive load I was trying to transfer to him.

If an executive has to reproduce your thought process step-by-step to understand a situation, why do they need you? Your role as a professional is not to flood leadership with context. It is to reduce, simplify, and provide just enough signal so a decision can be made.

The AI Generation Trap

Eight years ago, I treated writing as a craft. I loved shaping the narrative and presenting my way of thinking. Today, that dynamic has been completely inverted. With generative AI, everyone can produce polished, exhaustive text for a fraction of the cost in time and effort. Text has become a cheap commodity.

But the cost of reading has not changed.

Our human context window has not expanded. In fact, empirical data proves that as information volume increases, our cognitive bandwidth actively degrades. The numbers behind modern information overload are staggering:

• Continuous Interruption: According to Microsoft’s Work Trend Index, the average knowledge worker faces roughly 275 interruptions per day—about one every two minutes.

• Work About Work: Asana reports that 60% of a knowledge worker’s time is now consumed by coordination, reading, and app-toggling, leaving only 40% for the skilled work they were actually hired to do.

When a manager hands an executive a massive AI-generated document, they are failing Tesler’s Law. They are offloading the complexity directly onto an already overloaded system.

They are being cheap with their own time and incredibly expensive with their stakeholder’s time.

Progressive Disclosure: Building the Clean Interface

To absorb the complexity, you have to design a clean interface for decision-making. In UX design, we use a concept called Progressive Disclosure—showing the user the simplest interface first, and hiding the complex features behind an “Advanced Settings” menu.

You should apply this exact concept to your communication. Give stakeholders the clean UI at the top, and put the complexity at the bottom.

A clean text interface contains exactly three things:

1. The Context (1 sentence): What is the exact problem?

2. The Impact (1 visual or sentence): Why does it matter right now?

3. The Ask or Action (1 sentence): What do you need them to approve, or what are you doing to fix it?

The adage “a picture is worth a thousand words” is literal here. When I led a mobile engineering team, instead of elaborating on auto-update behaviors (they stopped listening after 15 seconds), I just opened Mixpanel and took a screenshot of the nice S-curve showing the move from app v1.0.0 to v1.1.0 over the last 4 weeks. “This is how our adoption cycle looks”. No questions asked since then.

If you need and worry that stakeholders will miss critical context, use a Technical Appendix. Put executive summary at the top, draw a line, and dump your context, data, and thought process at the bottom (or link to a Confluence page). Y

ou aren’t deleting the context; you are just removing it from the critical path.

Alongside this framework, apply these rules of reduction:

• Never say, “Here’s what ChatGPT says.” (I also hate getting such an answer…) An executive can prompt an LLM themselves. Your job is not to copy and paste AI outputs. Your job is to moderate, verify the logic, and separate the value from the fluff.

• Apply the Fatigue Heuristic. If a document is so long that you are tired of reading it yourself before hitting send, it is too long. The reader will feel that friction tenfold.

• Draft minus fifty percent. Stephen King notes in On Writing that his formula is Second Draft = First Draft - 10%. But King is a master of his craft. For those of us writing technical communications, our unedited thoughts are usually much noisier. Write the long, exhaustive thought process first to clear your head, but aim for a 50% reduction in your first round of edits. Brutally strip away the defensive posturing before you hit send.

• State the decision and give the green light to yourself. Default to making your communication a no-op. Rather than asking “can I push this change on Monday?”, go with “I’m pushing on Monday, here’s rationale. Let me know if you want me to hold on". You will be surprised by how much you will move forward, and your boss will be thankful for not being engaged in every single decision.

The Hidden Variable: Trust

Ultimately, the reason we over-communicate isn’t just because we have the tools to do it; it’s because we lack trust. We think we need to prove our competence with word count. We believe that if we don’t show all our math, people will assume we didn’t do the work.

The opposite is true. Drowning an executive in details doesn’t signal competence; it screams anxiety. It says, “I don’t know what actually matters here, so I’m giving you everything.”

Conciseness builds trust.

When an executive sees a short, sharp message that distills a massive technical failure into a three-bullet decision matrix, the implicit message is clear: “I have this under control.”

As a builder or an engineer, you don’t expose the circuit boards to the end user to prove how hard you worked. You give them a finished, functional product. Apply that same standard to your communication. Do the hard cognitive work of synthesizing the complexity, so your stakeholders don’t have to.

Supplemental reads

• Tesler’s Law - Managing Complexity of Software Systems

• The Leader-Leader Framework

• The Empathy Bottleneck - Why Brilliant Engineers Fail at Support

Read more

But here is a hard truth you need to swallow: if your team is always perfectly polite and measured with you, they are probably hiding something.

…

Read more

We love saying it. We think it signals to the room that we grasp the vast, complex, multi-dimensional chess game of software architecture.

We think it makes us sound incredibly smart.

In reality? You are doing one of two things: dodging the responsibility of making a hard call, or quietly bragging about your own technical brilliance wit…

Read more

The reality is far more nuanced. AI is not replacing the engineer; it is fundamentally redefining the baseline leverage of the role. We have reached a point where coding is no longer the bottleneck. Output is cheap, and syntax generation is ne…

Read more

The assumption is usually that I have some secret productivity hack or that I’m just working all the time. But working harder is a trap.

S…

Read more

For the last decade, the tech industry has popularized a very specific archetype of leadership: the det…

Read more

​While it contained tips on lighting fires and breaking machinery, its most devastating section focused on “bureauc…

Read more

Your job is no longer about whether we adopt AI, but about how we actually get a return on our investment without destabilizing our systems. Especially when C-level has been pushing you hard on this transf…

Read more

Spotify unveils Honk, an agentic platform that effortlessly updates hundreds of repositories in the background. “Spotify's top developers haven't manually written code since December 2025”.

Rippling announces Rippling AI, …

Read more

We shifted away from low-leverage interventions (like tweaking Jira story points) to high-leverage moves like shifting cultural paradigms.

But there is a middle layer that deserves an article entirely of its own: Feedback Loops and Information Flows.

As an engineering leader, we actively manage feedback loops every single day. We bounce between two extremes: offering vague, unhelpful praise or delivering relentless “constructive” criticism that grinds our teams down.

To build an autonomous, high-performing engineering culture, you have to understand the difference between Reinforcing Loops, Balancing Loops, and the critical process of Amplification.

The Two Loops of Leadership

In systems thinking, there are two types of feedback loops that govern how a system behaves.

1. Reinforcing Loops (The Accelerators)

Reinforcing loops compound. They amplify a behavior or result. In software, it’s tech debt (bad code makes it harder to write good code). In leadership, it’s how you scale culture. When you praise an engineer for writing excellent documentation, they write more of it, others see it, and a culture of documentation grows.

The Trap: Vague Reinforcement. Saying, “Hey, good job on that release” is empty calories. The engineer feels a momentary ego boost, but the system doesn’t learn what specific behavior to repeat.

The entire article is available only for paid subscribers. You can use the training budget (here’s a slide for your HR). Thanks for supporting Practical Engineering Management!

Read more

I have to admit, the chart of theoretical vs observed AI coverage stayed with me for longer. Math, computer science, admin & office, legal - I get these.

But management? Huh, that feels l…

Read more

A few months later, that cycle arrived. My reward? Nothing.

It was disappointing. Turbulent times and budget cuts, s…

Read more

When we were individual contributors, our code produced rapid, tangible outcomes. But as leaders, the effects of our decisions—or our passivity—often take months to surface.

Behind the scenes of our daily management, we are constantly fighting two invisible, relentle…

Read more

We spend months recruiting principal engineers, hoping that bringing top-tier talent into the same room will automatically translate into outlier results.

But there is a trap here that many engineering leaders fall into: we confuse a group of brilliant individuals with an actual, functioning team.

If you have a strong gro…

Read more

It resonated a lot. I remember my early times in the leadership, reading how Google, Spotify, and Amazon are managed - always frustrated about why we cannot do the same in our company.

Until I realized it’s not the company that is supposed to change. It is we, leaders, who drive this change, very often bottom-up.

You Manage System

As an engineering leader, you are essentially a system designer. You manage a complex socio-technical system—a web of people, processes, codebases, and infrastructure.

Early in our careers, we intuitively focus on technicalities: code, libs, APIs, UI components. But over time, we realize our work is on different levels too: tools and instruments (how these things are tied together) and finally, the social circuitry that includes the processes, standards, and communication patterns that guide how people work together.

The concept of three layers:

• Layer 1: Technical Objects

• Layer 2: Tools and Instrumentation

• Layer 3: Social Circuitry

It was perfectly explained in Gene Kim’s book "Wiring Winning Organizations," which I covered in a cycle of articles that starts here: Slowification: The First Step to Transforming Your Engineering Organization.

Leverage Points

Recently, I’ve read one of the most foundational texts in systems thinking: Donella Meadows’ essay “Leverage Points: Places to Intervene in a System”.

It explains that every complex system (organizations, companies, teams, economies) has places where a small change can produce a disproportionate effect.

Meadows’ core thesis is that people intuitively know systems have “leverage points” (where a small shift produces a big change), but for engineering leaders, the key insight is slightly uncomfortable:

Most leaders intervene in the least effective places.

They change metrics, budgets, or org charts while the real leverage sits deeper in information flows, incentives, and beliefs.

The original leverage points, as described in the article:

Here is how you can translate Meadows’ 12 leverage points into actionable insights for engineering leadership, moving from the least to the most transformative interventions.

The entire article is available only for paid subscribers. You can use the training budget (here’s a slide for your HR). Thanks for supporting Practical Engineering Management!

Read more

The real leverage sits in operations.

Over the last few weeks, I used AI to build a governance and observability dashboard on top of our no-code platform (Superblocks). Not to create apps faster. To control the chaos around them.

Surprise, no surprise: this wasn’t a hackathon toy anymore.
It became a working operational control system.

I’ve been building with AI for quite a long time, but this time my perception shifted to something new: code-as-a-service.

In this article, I will share my journey with building something in just a few weeks, which before took almost half a year for ops teams to capture.

We’ll walk through my real use cases, some dashboard previews and the solution I came up with to simplify management of our infra at a company scale.

The entire article is available only for paid subscribers. You can use the training budget (here’s a slide for your HR). Thanks for supporting Practical Engineering Management!

Read more

One of your strongest engineers walks in with an offer that looks like it escaped from another financial universe. Bigger salary. Better title. Sometimes both. Occasionally double or triple what you can reasonably propose.

For first-time engineering leaders, this hits like cold water.
It feels personal.
Like failure.
Like you “lo…

Read more

The reply became legend:

“Mr. President, I’m helping put a man on the moon.”

That story is my North Star in my daily job as an Engineering Site Leader at Papaya Global in Poland.

I want every engineer to have that level of clarity. To know exactly how…

Read more