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 like a target on our back.

The worst part? After being in leadership for many years now, I can say Anthropic isn’t wrong here…

The Death of the “Human Jira Router”

For the last decade, a dangerous percentage of engineering managers have operated purely as transactional leaders.

You treat engineers as scarce “resources.” You observe signals, schedule tasks, constantly reassign priorities, and act as a gatekeeper for product requirements.

Let’s be brutally honest: if your primary value to your company consists of asking “any blockers?” in standup, moving Jira tickets from left to right, and aggregating status updates into a spreadsheet for the Director, the AI of today can do the same, but ten times faster.

Moravec’s Paradox and the Lie of “Hard” Skills

Formulated in the 1980s, Moravec’s paradox states a counterintuitive truth: high-level reasoning requires very little computation, but low-level sensorimotor and social skills require enormous resources. In robotics, playing grandmaster-level chess is easy; walking up stairs is incredibly hard.

In 2026, we are watching this play out in knowledge work. For decades, we assumed our “hard” skills—sprint planning, analyzing velocity, debugging legacy systems, and drafting strategy memos—were the peak of our intellectual value.

We viewed “soft” skills—navigating organizational politics, sensing team burnout, or having a difficult 1:1—as the fuzzy, secondary stuff.

AI just flipped the script. The “hard” stuff is highly compressible, pattern-based, and easily automated. AI can write a perfectly empathetic-sounding feedback email.

But it cannot sit in a room with a defensive senior engineer, read their body language, understand the unspoken context of their recent divorce, and navigate the conversation to a place of psychological safety.

It can generate 1,000 lines of code, but it cannot inspire a burned-out team of missionaries to care about a pivoting product roadmap.

Evolve or Get Automated

To survive, you must pivot from being a taskmaster to being an environment architect. You must become a Developmental Leader.

Developmental leaders do not ask, “How do we get these tasks done faster?” They ask, “How do we advance the frontier of what is possible for this team?”

• You must Slowify: Give teams the context they need to think critically, rather than forcing them to react to tickets.

• You must Simplify: Break down complex architectures so the problems themselves are easier to tackle.

• You must Amplify: Build a culture of psychological safety where feedback is ruthless but kind, and problems are called out loudly, acknowledged, and acted on.

AI Needs a Human in the Loop (And That’s You)

The sheer volume of code generated in the coming years will be the highest in human history. Every junior developer with a Copilot license can bootstrap a microservice and generate 1,000 lines of edge-case test coverage in minutes.

But without human oversight, this isn’t productivity. It’s just noise.

Code is no longer the bottleneck; it is a liability. Your job is no longer to ensure code gets written—it is to ensure it is actually valuable, maintainable, and scalable. AI can act as a tactical coding assistant, but it cannot:

• Own the Technical Strategy: An LLM doesn’t know if a monolithic architecture or microservices better align with your startup’s dwindling runway and 3-year vision.

• Manage Complexity: Tesler’s Law dictates that complexity cannot be removed, only shifted. As AI makes it cheaper to generate features, system complexity will skyrocket. It is your job to proactively manage where that debt lives.

• Foster True Ownership: You cannot automate accountability. A culture of “You Build It, You Run It” requires a human spine. An LLM won’t wake up at 3 AM to mitigate a catastrophic production outage and then drive the blameless post-mortem.

From Software Engineering to Product Engineering

Perhaps the most un-automatable skill of the modern leader is product discovery.

Let’s look at the grim reality of our industry: only 10% to 30% of features pushed by tech companies actually yield positive commercial results. If your only measure of success relies on operational DORA metrics (Deployment Frequency, Lead Time for Changes), you are likely just building the wrong things, very efficiently.

If you run a feature factory, AI will easily replace you. It’s the perfect worker for a factory line.

Good managers ensure the team knows why they are building, not just what. They shift their teams from software engineering to product engineering.

End Words

We don’t need fewer engineering managers. We need fewer glorified babysitters.

If your job is to translate documents into tasks, the Anthropic data is your death sentence. But if your job is to untangle human complexity, hold the line on technical strategy, and scale the problem-solving capabilities of the humans around you?

You aren’t done. You are finally free to do the actual work.

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

It was disappointing. Turbulent times and budget cuts, so that I should just be happy I had stability.

But I couldn’t accept that.

I had done my absolute best to meet expectations and hadn’t hesitated to take responsibility for an organization and scope several times larger than before. So, after a few challenging discussions, I negotiated a different kind of compensation: I would work four days a week instead of five, for the same money.

That decision changed my life. I’ve covered the personal benefits in my yearly summary; here, I want to talk about what this did for my professional career.

Today, my working life operates in two completely different dynamics.

The Day Job: The Engineering Manager

For 4 days a week, I serve as an Engineering Director and Site Leader. I manage dozens of engineers across multiple domains and oversee an entire branch of nearly 100 people.

This is where I implement everything I write about on Practical Engineering Management:

• Basics: Career progression frameworks and expectation management.

• Center-Out Leadership: I set the direction and navigate with leverage points, but I delegate expertise to highly qualified Engineering Managers and Principal Engineers whose technical depth I couldn’t possibly match at my scale.

• Leader-to-Leaders Approach: I expect people to bring clear intent over permission-seeking. My teams must be able to act without my constant involvement.

• Data-Driven Focus: I expect to bring rich instrumentation to all we do.

• Problem-Solving Focus: Every big project must answer the following questions: what real problem it solves, for which stakeholders, and what metrics we will monitor after delivery.

• Strategic Compounding: Every initiative must compound over a 12-to-18-month timeframe, stemming from a solid Engineering Strategy Framework.

• More about how I lead my engineering teams can be found here.

I still care deeply about my job and put a lot of energy into it. But the moment I log off on Thursday afternoon, a completely different dynamic begins.

The Weekend: The Ultimate Builder

From Thursday afternoon to Monday morning, I become what I call “The Ultimate Builder.”

At first, this time was just for recovering from corporate burnout. But soon, with a refreshed perspective, I started Practical Engineering Management. Then I wrote a book. And finally, after years of corporate stagnation, I came back to coding.

Then the AI revolution hit.

Suddenly, what used to take me months now takes days. I don’t just build a single app; I build five simultaneously. I bootstrap, iterate, fail, and bounce back faster than ever before. Over a single weekend, I create more tangible output than I do in my day job over several weeks.

In the last four months alone, I’ve built:

• A fully integrated side-gig selling 3D-printed terrain for runners (from landing page to Stripe integration). You can see it on RunArt.pl.

• The complete custom tooling behind it: GPX parsers, SVG exporters, and 3D processing tools fetching DEM terrain from national geoportals into Three.js.

• A complete management system for OCR/Ninja gyms (rankings, challenges, leagues), soon going live to back a national league and multiple official competitions.

• Working prototypes of native mobile apps for athletes, I’m about to release in the following weeks.

Writing it out, it’s hard to believe how much tech I could cover: full-stack Next.js, Three.js, Android, 3D rendering, payment gateways, multi-cloud data processing, and more.

Why You Need to Build

I am sharing this because there are other Ultimate Builders out there.

I met them during multiple hackathons organized by local communities. These are Product Designers, PMs, business people or just regular engineers who jumped into the AI revolution and are bringing ideas to life at lightspeed. Today, they single-handedly create beautiful, functional, single-purpose solutions in a week that big organizations cannot deliver over multiple months.

They aren’t superhumans. It is simply easier than ever to build.

But you won’t see this if you are trapped in a cycle of calculating story points and meeting unrealistic deadlines you committed to during quarterly planning six months ago.

Don’t get me wrong—don’t quit your corporate job. It brings stability, scale, and capital you rarely get from a side gig.

But you must carve out a day or two to see the outside world. You need to build freely, bootstrap your own ideas, and slowly establish your independence. So when the time is right—or when the future wave of layoffs hits today’s high performers like you—you will be ready.

With your mindset and the tools available to you, you can be a powerful builder.

What’s Next for Practical Engineering Management?

This brings me to a crossroads, and I need your honest opinion about the content I bring here. Please write it here, via DM or simply on mirek@practicalengineering.management

The traditional boundaries of Engineering Management are blurring. In the age of AI, our leadership skills are no longer limited to managing human teams within a single organization. We are moving from managing people to managing systems, agents, and rapid product lifecycles.

Do you want to keep reading strictly about traditional “Practical Engineering Management,” or are you ready to pivot into the world of the “Ultimate Builder,” where we apply our management frameworks to 10x our individual output?

There has never been a better time to create. Your energy can go into being a 20% better manager or a 10x better builder. (Or, if you play your cards right, both).

What’s your call?

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, relentless laws of physics: Entropy and Inertia.

Nowhere are these forces more destructive than when dealing with a chronic underperformer or a cultural detractor.

If you scroll through LinkedIn or other leadership sources, firing is overwhelmingly framed as a failure of leadership.

We are told to coach, to mentor, to find them a different seat on the bus. But there is a hidden hack to building high-performing cultures that no one wants to talk about:

Removing the “rotten apple” is often the single most effective way to fight organizational decay and increase your team’s output.

The Capacity Sink (Human Entropy)

In physics, entropy is the measure of disorder in a system. According to the second law of thermodynamics, entropy always increases unless energy is applied to stop it.

We usually talk about technical entropy—systems becoming overly complex, technical debt accumulating, and codebases decaying. But there is also Human Entropy.

Recently, I was speaking with another engineering leader who shared a brilliant framing for evaluating a struggling team member.

They rely on one simple question:

“Does this person add capacity to the team, or take it away?”

When someone is a chronic low-performer or an asshole, they don’t just contribute zero—they operate in the negative. They act as a human catalyst for entropy.

They drain your senior engineers’ time with repeated, basic hand-holding. They make code reviews exhausting. They introduce toxic friction that occupies the mental and emotional space of their peers.

They are a capacity sink.

Unaddressed, this human entropy paralyzes the team. The group would literally get more done, faster, and with less stress, if that person simply wasn’t there.

The “Nice Leader” Trap (Overcoming Inertia)

If human entropy is the disease, why do we wait so long to apply the cure? The answer is the second force: Inertia.

Inertia is the resistance to change; it’s the tendency of an object to keep doing exactly what it’s doing. For engineering leaders, organizational inertia often disguises itself as empathy.

I speak from experience because I fell into this trap myself. For years, I had situations where I hesitated to fire someone who was clearly dragging the team down. Because I wanted to be a “good” leader, I waited. I tried to find them a new project. I moved them to a different squad. I convinced myself I was giving them a fair chance.

But the reality was just psychological inertia. Our brains are wired to favor familiar patterns and resist change because it burns much less energy.

It is emotionally easier to stick with the familiar discomfort of a failing employee than to face the sharp, disruptive reality of firing them.

I thought I was being empathetic. Driven by my own thoughts of Developmental Leadership.

I was actually just being lazy and negligent.

What You Tolerate, You Encourage

Here is the hard truth about letting inertia win: Your high performers are watching.

When you keep a net-negative performer on the team, you aren’t just “helping” that one person. You are sending a loud, clear signal to everyone else: “This level of performance is acceptable here.”

I realized my hesitation was creating a sense of deep inequality. My top engineers were asking themselves a dangerous question: “Why am I working this hard, pushing for quality, and sweating the details, when the manager is perfectly okay with keeping someone who drags us down?”

By shielding the low performer from consequences, I was disrespecting the people who were actually carrying the team. Slowly, the performance of my good engineers started to degrade because I had effectively lowered the bar to the floor.

I allowed entropy to spread.

The Silent Expectation

We often fear that firing someone will disrupt the team and make people feel insecure. We worry they will think, “Am I next?”

But in my experience, the opposite happens. The rest of the group knows about the capacity sink long before you do. They are the ones fixing the broken code and enduring the negativity.

They are silently expecting you to do your job.

When I finally fought through the inertia and made the decision to let those individuals go, yes, there was an initial shock. For a week or two, the air felt heavy. But once the dust settled? The relief was palpable.

“We knew it was right. We didn’t know why you hesitated for so long,” - this is what I heard from one of the principal engineers a few months later.

The velocity went up. The culture solidified. The team realized that I was willing to apply the necessary force to correct the system and protect their working environment.

Finding “The Line”

I’m not suggesting we rule with an iron fist or fire people for a single mistake. Coaching and grace absolutely have their place.

But as leaders, it is our primary job to fight entropy and inertia, and that means defining “The Line.”

When does “support” become “enabling”? When does “patience” become “negligence”?

If you have been clear about expectations, provided support, and the person is still actively draining capacity from your team, you have reached the line. Crossing it means you are sacrificing the productivity of your best people to protect the comfort of your worst.

It is not a “bad” thing to fire people. It is a necessary function of guarding your company’s culture. Don’t wait years like I did.

If you are holding onto someone purely because it’s easier than letting them go, look at your high performers. They are the ones paying the price for your inertia.

Supplemental reads

• Managing Growth and Expectations in Engineering Teams

• Developmental Leadership vs. Transactional Leadership

• You Need No Heroes

• When You Can’t Match the Offer

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

This article is inspired by what I took from this year’s talk. Sadly, his last keynote.

Read more

Engineering teams burn cycles debating how to integrate OpenAI or Claude, wire agents into CI/CD, build custom IDE plugins, or wrap raw LLM APIs.

This is a solved problem.

GitHub, JetBrains, Microsoft, and others already built these pipes. Integration is no longer the challenge. It’s a commodity.

The real bottleneck, and the real competitive advantage, lies elsewhere:

What you feed the model.

To move from playing with AI to creating durable enterprise value, we must shift our attention:

1. from integration to data

2. from increasing cognitive load to deliberately reducing it

Full article and supporting materials are available to paid subscribers, including:

• Practical solutions and standards

• Case studies and examples

• Exercise for you

You can use the training budget (here’s a slide for your HR).
Thanks for supporting Practical Engineering Management!

Read more

Most of them are just adding noise.

With AI:
Slack is louder.
Docs are longer.
Budgets are higher.
Bud roadmaps are somehow… slower 🤷

The uncomfortable truth is this:

AI rarely fails because of models. It fails because of engineers.

After watching multiple teams “adopt AI,” the same personalities keep showing up.
Recogniz…

Read more

Will it replace humans?
Will it take jobs?
Will engineers still be needed?

Those questions are loud.
And mostly irrelevant.

The real question for engineering leaders is quieter and more uncomfortable:

How do we make sure our teams don’t lose the ability to think, judge, and decide once AI starts doing most of the visible work?

Because AI doesn’t fail by being weak.
It fails by being good enough.

The Lens That Changed the Question

Some time ago, while reading User Friendly by Cliff Kuang, one example stayed with me longer than the others.

The book explores how automation and design don’t just make systems easier to use — they quietly reshape human capability.

In one case, automation made pilots safer and more efficient in normal conditions, while slowly eroding the very skills they needed when something went wrong. Not because they were careless, but because the system no longer required them to practice those skills daily.

Once you start looking at AI through that lens, the question stops being whether it replaces humans — and becomes whether it slowly trains them out of the profession they’re supposed to master.

This Isn’t Just a Feeling

Studies on the out-of-the-loop problem show that when people shift from doing the work to monitoring automated systems, their situational awareness degrades and their responses become slower and less reliable when something goes wrong.

Researchers Parasuraman and Riley captured this dynamic precisely in their “use, misuse, disuse, and abuse” model of automation, showing how overreliance on systems that usually work leads to complacency and judgment errors even among trained professionals.

The FAA has repeatedly warned about skill degradation in highly automated cockpits and explicitly requires ongoing manual-flight training to keep pilots capable when automation fails.

Automation Is Not the Problem. Atrophy Is.

We’ve automated before.

Compilers replaced assembly.
Frameworks replaced boilerplate.
Cloud platforms replaced data centers.

Each wave removed effort.
Each wave raised the abstraction.

But AI is different in one crucial way.

It doesn’t just automate execution. It automates reasoning-shaped outputs. Code, architectures, plans, analysis, documentation.

Things that used to train our professional judgment.

And that’s where the danger lies.

Not in replacement.
But in skill atrophy hidden behind productivity gains.

Full article and supporting materials are available to paid subscribers

You can use the training budget (here’s a slide for your HR).
Thanks for supporting Practical Engineering Management!

Read more

This article zooms in on just one element of that framework.

The most practical one.
The one you can run with your team next week.

The Friction Board.

Where This Comes From

The Friction Board is inspired by the book User Friendly by Cliff Kuang and Robert Fabricant — and especially by Fabricant’s afterword:

“The World Seen Through the Prism of User-Friendly Design.”

That afterword reframes design not as aesthetics or usability tweaks, but as a way of shaping how people understand and act in the world.

This framework is my attempt to translate that idea into engineering language:

• not taste

• not opinion

• but observable behavior and mental models

Most teams don’t struggle because they lack ideas.

They struggle because they solve the wrong problem, extremely well.

An engineer sees confusion and thinks:
We need clearer logic.

A product manager sees confusion and thinks:
We need a better flow.

A designer sees confusion and thinks:
We need better copy.

The Friction Board exists to find the common language.

What the Friction Board Is (And Is Not)

The Friction Board is not:

• a feature ideation workshop

• a UX critique

• a backlog grooming session

It is an observation tool.

A way to surface one sentence:

“This feels hard because…”

Before anyone proposes how to fix it.

The entire article with The User-Friendly Engineering Framework materials 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

CI is green.
Latency is fine.
No errors in logs.

And yet customers still hesitate.

They click, pause, go back.
They open tickets that start with:
“I thought this would…”

So we respond like engineers.

We add a tooltip.
Write documentation.
Record a Loom.

But the real problem isn’t the missing explanation.

The system behaves correctly — but it teaches the wrong mental model.

And that’s the uncomfortable truth behind user-friendly products:

Engineering doesn’t ship code.
It ships behavior.

I ran into this problem years ago, before I had language for it.

While leading a mobile engineering team, we implemented a feature that let users reuse a card for recurring payments.

There was a constraint:
we couldn’t store full card details, so the card could only be reused in that specific recurring flow, not everywhere.

From an engineering perspective, it was a neat solution. So we explained it like this:

“We’ll save your card for this recurring payment.”

Technically true. But users understood something else entirely.

They assumed their card was saved in general.
They expected it to work in all future payments.
And when it didn’t, they experienced it as data loss.

Nothing was broken in the moment.
The failure appeared later, in a different flow, at a different time.

Eventually, we stopped talking about “saving the card” at all.
We framed it purely as recurring payments.

That’s when it clicked for me:

You can design a perfectly working screen —
and still break the user journey.

The Missing Lens for Engineering Leaders

Good engineering is about building systems.
Great engineering is about making them feel obvious

And that’s the lens most engineering leaders were never taught to use.

Some time ago, I picked up “User Friendly” by Cliff Kuang.

It’s a book about how products quietly shape human behavior — how small design decisions change what people do, what they trust, and how much mental effort they have to spend just to get through their day.

That, to me, is exactly the territory engineering leaders should operate in.

Most engineers were trained to think in systems:

inputs and outputs
contracts and guarantees
happy paths and edge cases

Design, on the other hand, often sounds vague.
Emotional.
Subjective.

But User Friendly makes one thing very clear:

Good design is not about taste.
It’s about reducing human confusion.

I tried to translate that idea into engineering language.

Below is the User-Friendly Engineering Framework, rewritten specifically for software engineers who don’t think of themselves as designers —
but already are.

The User-Friendly Engineering Framework

Each pillar answers one question:

“Why does this system feel harder than it needs to be?”

The entire article with The User-Friendly Engineering Framework materials are 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

Focus.
Pick one thing.
Execute relentlessly.

It’s nothing bad about it. But it’s just aimed at the wrong role.

Leadership Is Not About Certainty

By the time you become an engineering leader, almost everything you touch is uncertain.

Projects.
Product bets.
Architecture changes.
Hiring decisions.
Reorgs.

Even the initiatives that arrive with executive blessing are not truths. They are hypotheses dressed as plans (more about it here).

We rarely say this out loud, but it’s true:

Most initiatives fail.
Some quietly.
Some politically.
Some after months of sunk effort.

And yet we often behave as if our job is to make one of them succeed at all costs.

That’s the trap.

Your Job Is Not to Win One Bet

There’s a line from Sundar Pichai's interview that stuck with me. He said that his job is simply to move the needle.

At first, that sounds vague. But over time, I think I came to understand what he meant.

Moving the needle is not about defending a single initiative.
It’s about shifting the odds.

Full article and supporting materials are available to paid subscribers, including:

• Leadership probability thinking

• Concurrency limits and portfolio mindset

• A practical weekly leadership operating model

You can use the training budget (here’s a slide for your HR).
Thanks for supporting Practical Engineering Management!

Read more

A quiet tension. A sense that AI isn’t just a new tool — it’s a structural shift.
A force that will reshape how we build, how we organize, and who we need on our teams.

But the conversation is often… shallow.

People keep asking “Will AI replace engineers?” or “Will it make teams…

Read more

I’ve been writing weekly issues of this newsletter every single week for two years now.

While most of my pieces focus on the practicalities of engineering leadership, this one is slightly different.

If you’re looking for another piece of practical advice, feel free to skip it and save your time.

This is just my personal story.
With some facts from my life not directly related to software engineering.

I’m writing this mainly for myself.
To reflect on where I am, professionally and personally.
And to assess the direction I’ve been driving myself toward.

This Year Was a Blast for My Engineering Career

When I look back on the past months, it’s been a ride.

I learned multiple aspects of AI.
I wrote a few production apps in fully agentic mode.
I drove the adoption of these practices in the organization I’ve been leading.

I manage an engineering site in Poland.
The office. The people. The processes. Hiring. And more.

I also took the lead over full platform engineering
DevOps, Backend, and Frontend
serving Infrastructure and DevEx practices for over a hundred engineers across the company.

I did some open source work and, thanks to AI, came back to almost everyday coding after years of stagnation.

I wrote a book.
I create this newsletter.
And I had my talk at the Infoshare conference.

I genuinely love software engineering. I’m also very excited about connecting this world with product and business, and about building solutions people actually love.

I Could Have Been a CTO, But I’ve Chosen Not To

At some point in their career, almost every engineer thinks about becoming a CTO.

I did too.
Especially in my early days.

Looking only at my experiences from this year, I’m pretty sure I could already be one.

In fact, I’ve rejected a few such propositions.

Worldwide impact.
Stock options.
Raw power.

Plus the fact that I genuinely love what I do professionally.

Am I dumb to reject such a life
or the life that might come after an IPO?

Maybe.
Who knows.

But today, I’m choosing not to dedicate 100% of my life to my profession.

I don’t even work full-time at my job.

Instead of traveling the world, visiting the biggest tech conferences overseas, and being fully immersed in the tech bubble, I choose to be a 9–5 part-time worker.

And to play other personas for the rest of my time.

I Am a Runner

This year, I started a coached program with up to six trainings a week. For a few years now, I’ve been doing Obstacle Course Racing mixed with trail running. I love it and I’m curious how far I can go.

I won’t lie: the program was hard. My baseline in January was challenging, as I was coming back to sport after a foot fracture that had healed just a month earlier.

Over the year, I did almost 300 trainings: strength, endurance, obstacle/ninja, and a lot of running.

For the first time in my life, my training was so well structured. Intervals on flats and ascents, fartlek runs in terrain, and my first experiences on an athletic track. My favorite runs are 10–15 km in hilly terrain, ideally with moody conditions: early morning, fog, maybe a bit of rain.

I raced Spartan Race, Barbarian Race, and Runmageddon, as well as trail races like Tatra Trail. Distances ranged from 6 km to 25 km, on hills and flats, in forests, in 30-degree heat, and in -1°C frost. I also tried sprint-like races with 400 meters and 10+ obstacles.

At my peak, I was the 29th Elite Racer in Poland and 15th in my age group. I think I can do slightly better; there’s still some margin. But even this performance is extremely satisfying, especially for someone who does software engineering for a living.

But running wasn’t only about racing.

I ran through many magical places: city runs through Bern, uphill runs in the Alps above Innsbruck, trail runs through Swiss villages, and countless dawn runs through silent, empty, foggy forests near my home. And one bucket list item: uphill running on Copenhagen’s Copenhill.

I Am a Photographer

I love photography. I keep learning composition and light. I shoot with my phone, GoPro, my small Sony RX100, and a larger OMD EM-5. I enjoy shooting vibrant cities, landscapes, golden hour light, sunsets, and sunrises.

But my ultimate project is this: I take my camera, usually the RX100, sometimes a GoPro, and I shoot during my runs.

I shoot from a runner’s perspective.

The mood I love most comes from early morning fog in forests, but I also enjoy sleepy cities just after sunrise or colorful sunsets.

The rule is simple. I stop for a few seconds, don’t even pause my Garmin watch, point, shoot, and keep running.

This project is about showing how beautiful running can be. Literally.

This year, I printed my photos and framed them for the first time. Since then, I’ve known that one day I want my own gallery dedicated to photography through a runner’s eyes.

I Am a Ninja

I already do quite a lot of sport, yet there’s another derivative of my training: ninja.

If you’ve watched Ninja Warrior, that’s exactly it.

I’m too cautious to go all-in; the risk of injury in this discipline is already too high for me. But I’ve learned a lot: jumping between bars, salmon ladders, rope variations, and other ninja obstacles.

After each of my trainings, I spend another 15–20 minutes practicing ninja skills. This year, I felt confident enough to take part in local ninja competitions, which I did. And I absolutely loved it.

Here’s just my regular after-training fun:

I Am a Present Dad

Running, photography, coding. That’s already a lot about me.
Yet there’s still plenty of space in my heart for family.

It doesn’t come naturally to me. I’m a lone wolf, a thinker, a dreamer. I was also raised in a classic family model, where women handled childcare and home, and men focused on work.

Still, I’m proud of being a present dad to my five-year-old daughter. From changing diapers, to doctor visits, to feeding, to simply growing up together, I put a lot of effort into splitting these responsibilities equally with my wife.

But it’s more than logistics.

My daughter and I train ninja together. We’ve done kids’ OCR races like Spartan Kids. We listen to vinyls from Linkin Park, Trolls, AC/DC, and Eminem. We have a bucket list of all science centers in Poland. When my wife is away for a weekend, we build Hot Wheels tracks across the entire apartment.

We laugh a lot. We argue a lot. We respect each other’s boundaries, moods, and emotions.

We also took our first solo trip together. No car, no mom. Just a backpack and hundreds of kilometers of travel.

Yes, my daughter still defaults to my wife. She shows her more emotions, prefers hugging her, and complains about me to her. But I know I have a place in my child’s heart too.

Being a present dad is hard.
But it’s also extremely rewarding.
Like nothing else.

I Love Science, Design, and Art

I was fortunate to travel a lot this year: Bern, Copenhagen, London, and multiple smaller cities and towns. When I look back, these are some of my core memories 👇

Reading Carlo Rovelli’s White Holes and Michio Kaku’s Hyperspace and Quantum Supremacy, and visiting Einstein’s home in Bern. That trip also reminded me of visiting CERN during its open days in 2019.

A few months later, I visited London and randomly stumbled upon IBM’s quantum computer. I wasn’t aware it was there; I literally noticed it while wandering the city.

London brought even more. Passing by Orwell’s home awakened memories of 1984, a book that deeply moved me a few years ago. Then the Wright brothers’ Flyer replica, the Greenwich Observatory, Da Vinci’s notes in the British Museum, Raphael’s paintings, and Michelangelo’s sculptures. All revisited after a few years away from London.

And the absolute cherry on top: Maman, Louise Bourgeois’ spider, returned to Tate Modern. Another bucket list item checked, after seeing her spiders in Tokyo, Amsterdam, and San Francisco.

I already mentioned Copenhagen’s Copenhill, but that trip was much more. I’m fascinated by Scandinavian design, so seeing the city and visiting the Danish Architecture Center were unforgettable experiences.

I Love Life

On one of my return trips, I took out my notebook and wrote random words and memories from this year. In this summary, I’ve probably covered only 20–30%.

My Nuuna notebook holds much more:

• Seeing a huge moose during a solo early-morning run in an empty forest

• Blausee, the blue lake in Switzerland

• Running at 5 a.m., before sunrise

• My first OCR race: 21 km in sub-zero temperatures

• Personalizing my office with printed photos, plants (and first blooms!), and bookshelves full of inspiring books

• Swimming in a lake for the first time in my life

• Driving thousands of kilometers across the Alps

• Taking 4th place in a ninja competition

• Writing more code in the last months than in several previous years combined

• Returning to trail running after my foot fracture

• Chocolate factories in Poland (Wedel) and Switzerland (Läderach)

• Traveling across Poland for OCR races

• The sound of birds in an empty forest at 6 a.m. during a run

• Spending an entire weekend, from morning till night, with my daughter at the Ninja European Championships

And much, much more.

End Words

So what’s the point of this summary?

I’m someone who tends to fully immerse myself in things. I deeply buy into company missions and visions. I believe in changing the world. I always wanted to be better, more impactful.

But over time, a few things changed. The birth of my daughter. Then, moving to part-time work. These initial cracks slowly became doorways to new paths in my life.

I believe I’m still very impactful as an engineering leader and that I still do good for the world and the people around me. But today, I’m more than that.

I’m a runner.
A dad.
A photographer.
A husband.
A ninja.

I’m sensitive to art, science, and the world around me.

Titles and impact are no longer the only measures of my life. They’re just part of a much richer whole.

I’m leaving this here as a message to myself.
To my past self and my future self.

If you made it to the end, thank you for reading.
I hope you found a bit of inspiration for yourself.

All the best,
Mirek

“Build an app in a day.”
“Ship features in hours.”

And yet… inside most companies, the reality is different:

AI generates a mountain of code.
Engineers spend time cleaning it up.
Velocity doesn’t move.
Quality drops.
Leaders start doubting the whole thing.

Because here’s the uncomfortable truth:

AI doesn’t replace engineering.
AI multiplies whatever engineering discipline you already have. (It’s DORA 2025 confirmed fact)

If your codebase is chaotic → AI accelerates the chaos.
If your standards are unclear → AI hallucinates.
If your feedback loops are weak → AI reinforces the weakness.

But here’s the other truth nobody talks about:

This is the biggest opportunity for software engineers and engineering leaders in 20 years.

Not to vibe-code.
But to become Operators — people who can shape intent, set constraints, and orchestrate AI’s output safely and predictably.

The AI Future Isn’t Automation. It’s Orchestration.

AI won’t take your job.
But someone who knows how to operate AI absolutely will.

Because the real leverage isn’t in typing code — it’s in:

• Defining the spec so AI knows what “good” looks like.

• Setting evals so AI can self-correct before you ever review a PR.

• Providing context so AI works within your architecture and building blocks, not against them.

• Designing feedback loops so you validate work in minutes, not weeks.

Those aren’t skills of the future. They are skills for today’s survival and tomorrow’s leverage.

A Practical Preview — Straight From the Book

If you want a simple, high-leverage exercise that will improve your AI output today, try this:

The “Vague → Vivid” Rewrite

Take one real task from your backlog — something simple like:

“Add search to the product page.”

Now rewrite it as if you’re onboarding a brand-new engineer who has zero context.

Example:

“In pages/ProductPage.tsx, render <SearchInput />.
Call productService.search(q) with a 250ms debounce.
Match results to ListItem component.
Ensure all tests in search.test.ts pass.”

Same system.
Same AI model.
Completely different outcome.

This tiny shift alone reduces hallucinations, shrinks diffs, and cuts review time dramatically.

And it’s just one of the 60+ practices inside the workbook I wrote.

Where This All Leads

Over the next few years, every engineering team will face the same strategic choices:

• Where should AI help — discovery, prototyping, or production builds?

• How do we keep speed without losing safety?

• How do we prevent quality from collapsing under 10× output?

• How do engineers grow when AI writes more of the code?

The teams that win won’t be the ones generating the most lines of code.

They’ll be the ones who:

• write the clearest specs

• maintain the best standards

• enforce the tightest eval loops

• and orchestrate AI with the discipline of operators

This is the new craft.
This is the new advantage.

And this is exactly why I wrote the book.

“From Engineers to Operators — The AI Strategy Workbook”

This workbook is my field guide for engineering leaders and ICs navigating the AI era.

It includes:

• Why AI works for some teams but not others

• The Operator mindset (spec → eval → context → operate)

• Frameworks for prototyping, delivery, and agentic development

• Practical prompts and templates you can use tomorrow

• How to design safe, reversible, high-velocity AI workflows

• A one-page adoption scorecard for measuring impact

Read the free chapter from the book here.

And yes — there’s a 7-day money-back guarantee.
If it doesn’t help you become a better operator of AI, you get a full refund.

Final Thought

The AI hype will fade.
The AI craft will stay.

Engineers who learn to operate AI — not fear it, not worship it — will define the next decade of software development.

If you’re serious about leading your team through the AI era — beyond hype, toward leverage — check out the book here and start turning experiments into impact.

Let’s build what’s next — not fear it.

Psst, if you are a paying subscriber, here’s a discount for you 👇

Read more

Strong engineering skills, saw both plenty of greenfield and legacy. Built products alone, worked in teams, dabbled in AI before it was cool. On demand, he could spin up a micro-startup in mobile or frontend technologies.

His question wasn’t:

“Should I become a manager, start a company, or pivot to another engineering career?”

It was sharper:

“I know myself pretty well. There are too many options.
I don’t want you to tell me what to choose.
I want to know how to choose.”

That’s the right question for 2026.

Because the game has changed:

• Layoffs are real.

• AI isn’t going away, and code is cheaper.

• Expectations are higher.

The problem is no longer “Will there be jobs?”
The problem is: Which people will those jobs be for?

1. The uncomfortable truth: some roles really are dying

Over the last years, we’ve seen:

• Hundreds of thousands of layoffs in tech

• Ongoing “skills shortage” at the same time

• Executives talking about talent density, not headcount

It’s not a paradox.
Companies don’t want more people. They want more impact per person.
AI is enabling that, but only for those who know how to navigate.

Three profiles are especially fragile going into 2026:

Factory-style testers

People who:

• Manually click through regression checklists all week

• Sit in the middle of a dev → QA → release pipeline

• Are the “gate” that everyone waits on for a green light

In organizations shipping multiple times a day, this model doesn’t scale. Automation eats it.

Here’s the harsh truth: Engineers who design for testability replace those who only execute test cases.

With AI, the challenge is on a whole new scale. Not because AI writes all of the tests. It’s because AI requires fast feedback loops, which regular QA testers cannot provide.

Coders who only “take tickets”

AI + better tooling + global talent have exposed a harsh category:

People who:

• Wait for perfect Jira tickets

• Don’t care what problem the feature solves

• Don’t know how the product is used

• Celebrate “Done” in Jira as the end of their responsibility

That role is being commoditized.

Cursor, Copilot, v0, etc. make it trivial to produce functioning code.
What they don’t do is:

• Understand the business context

• Decide what’s worth building

• Make trade-offs under constraints

• Own the outcome after deployment

Pure ticket-takers are sitting exactly where AI + cheaper labor + platforms hit first. It doesn’t matter that you deliver tickets quickly. Productivity was never about how much you can produce but how much real value you can generate.

What We Bring

Product Sense, Not Just Technical Skills

We understand users, business models, and market dynamics.
We’ve grown product sense through years of seeing what works and what doesn’t.
We’re not just coders—we’re problem solvers who happen to use code as our medium.

Read More on Product Engineering Manifesto

Transactional managers

2024 already showed the direction:

• Fewer managers per IC

• Larger teams per remaining leader

• EM roles cut or transformed into more hands-on positions

The riskiest leaders in 2026:

• Professional schedulers and resourcers

• People whose “job” is: keep the board updated, run standups, escalate blockers

• Managers who can’t articulate their value beyond “coordination.”

In a world where AI can summarize, update tickets, and draft status reports, this is not a durable advantage.

The leaders who stay are those who act as force multipliers:

• Set standards and expectations

• Shape architecture and practices

• Bridge product, tech, and business

• Reduce cognitive load and complexity

In the future, where we move From Engineers to AI Operators, these skills - keeping AI “on a leash” - specifying what good looks like, evaluating the output, and constant iterations, will become a critical part of our work.

2. AI isn’t replacing engineers. It’s amplifying the gap.

Let’s get AI out of the way.

No, it’s not going to flip a switch and fire every engineer overnight.
But it is doing three things you can’t ignore:

1. Making coding faster
   Coding agents can cut the coding time for some tasks in half or shorter. Whether you like it or not.

2. Exposing waste
   If AI can generate features in days and still two-thirds of them don’t move the needle, it becomes painfully obvious the problem was never “too slow coding.” It was “building the wrong things” (According to Marty Cagan’s book Transformed, only 10-30% of shipped features actually yield positive outcomes).

3. Compressing teams
   If one engineer can ship what used to take two or three, orgs won’t keep the exact headcount forever. They’ll bet on smaller, stronger teams.

Which means:

AI doesn’t kill engineering.
It kills low-leverage ways of doing engineering.

The people at risk are not juniors.
It’s those who cling to the old job definition:

“You tell me what to build.
I’ll write the code.
We’ll measure success by ‘velocity.’”

That’s the role AI will happily chew through.

The entire article and PDF/docs are 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