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.

Somewhere between professional and unprofessional communication lies the actual truth.

Let me explain.

Lately, I shared some news with my engineers: we might have to shut down access to their favorite IDE.

The reaction wasn’t a polite, “Let’s align on the business impact of this tooling shift.” It was heated. Some engineers dropped a few colorful words. Others half-joked that they’d start updating their resumes. Some bluntly told me that the company was shooting itself in the foot. “Are you joking, right?”

Honestly, a few years ago, such a reaction usually made me either upset or disappointed. Always asked myself, “Don’t they really see the big picture of this change?”

Today, it’s more of a relief.

Why? Because that raw, unfiltered frustration is the ultimate metric of psychological safety.

Harvard researcher Amy Edmondson discovered this years ago. When she first started studying medical teams in the 90s, she assumed teams with better dynamics would make fewer errors. When the data came back, she was horrified: the 'best' teams were reporting significantly more errors. It took her a while to realize she hadn't found a breakdown in teamwork; she had discovered psychological safety. The failing teams looked perfect on paper because they were terrified to speak up. The successful teams were messy because they felt safe enough to admit the truth without fear of punishment.

Read more here: The Intelligent Failure that Led to the Discovery of Psychological Safety

My engineers felt secure enough to look their Site Director in the eye and tell me exactly how stupid they thought the idea was. 🤷

Contrast that with a conversation I had recently with another manager, who came to me complaining about some feedback they’d received (I’m a dotted-line manager here). “This engineer from your site told me they are pissed off about the senior management’s latest decision. I think this is highly disrespectful and completely unprofessional.”

My response? “Maybe. But it’s also a sign they trust you.”

I told this manager the quiet part out loud: That engineer would never have spoken like that to the CEO or the CTO. They would have chosen the more dangerous path of remaining silent, bottling up their frustration, and quietly disengaging right up until the day they handed in their notice.

Andy Grove, the legendary CEO who built Intel, wrote the Silicon Valley bible on leadership, High Output Management.

He didn't just tolerate messy disagreements; he engineered his entire corporate culture around a concept he called 'constructive confrontation.' Intel actually required new employees to take classes on it. Grove demanded that people ferociously argue with one another over the work. He recognized a reality that modern management often forgets: high-tech environments require brutal honesty. In his eyes, prioritizing politeness and consensus over truth wasn't just unprofessional; it was a threat to the company's survival.

A side note on the book: At its core, High Output Management treats a company like a manufacturing plant and a manager like the engineer optimizing that plant.

Grove completely destroys the idea of the “individual contributor manager.” He replaces it with one cold, indisputable equation:

A manager’s output = the output of their team + the output of the neighboring teams they influence.

If your engineers are shipping slowly, building the wrong things, or bogged down in broken processes, your output is zero—no matter how many hours you worked or how many emails you sent.

A Slack prank

If you want proof of how messy, human behavior beats sterile corporate processes, look at the classic office prank: an engineer walks away from an unlocked laptop, and a teammate posts a ridiculous or shameful message on Slack on their behalf.

Honestly, I hate it. But let’s look at the mechanics under the hood: that one slightly unprofessional, embarrassing joke does more to enforce actual security habits—making sure people lock their screens—than a dozen sterile, mandatory, in-house infosec compliance forms. The messy, informal reality drives the actual outcome. The professional checklist just checks a box.

Yet, if you look at old, cold-style corporates, top managers remain completely detached from this reality. They sit in their ivory towers expecting everyone to be emotionless cogs. They worship cold data and numbers, ignore the friction of human feedback, and demand that all communication be sanitized before it reaches their desks.

As I’ve explored before regarding Westrum’s organizational culture, these are your classic Pathological and Bureaucratic environments. They value rules and turf over results, and the messenger is routinely shot.

But Generative cultures—the ones that actually innovate and win—focus on the mission. And the mission requires the unvarnished truth.

When you demand absolute professionalism at all times, you don’t eliminate the frustration, the risks, or the bad ideas. You just drive them underground. You trade the messy truth for a comfortable lie.

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 without providing a single shred of actual value.

Let’s be brutally honest. Most of the time, we retreat into “it depends” because we simply do not know what our boss wants to hear. Playing it safe, we list out every conceivable option.

But realize what happens in that exact moment: you are delegating your responsibility upward. By forcing your boss to sift through the options and make the final call, you render yourself virtually useless. You are acting as a researcher—a role that can now easily be replaced by AI—instead of doing the hard work of making a decision and owning the consequences.

Stop doing it.

You are in the room because you are an expert. No one is asking you for a philosophical dissertation on the infinite possibilities of system design. They did not come to you to buy more uncertainty, to get more problems, or to leave with more questions than they walked in with.

Handle it entirely differently. Rather than endlessly deliberating, bring a maximum of two options to the table and state: “I chose the first option, and I am moving forward with it unless you clearly disagree and tell me what I should do instead.”

In this scenario, you show that even if they abstain from making the decision, you are ready to act. You picked your way. It forces a clean resolution: they either give you the green light (which is exactly what you want), or they actively step in and put their own alternative on the table.

If you truly do not know the answer, do not hide behind the illusion of complexity. Just say, “I don’t know.” It takes far more confidence to admit ignorance than it does to waffle.

But if you do know, cut the bullshit. Stop acting like a consultant and start acting like a Product Engineer.

Product Engineering is not about listing every possible edge case; it is about bringing clarity, hard numbers, and hypotheses you are willing to validate. It is about understanding the current telemetry—both technical and product—and defining exactly what scale you can handle, what scale you predict, and which friction points you are going to erase.

Let me give you a concrete example. Recently, one of my principal engineers for platform engineering came to me about a massive infrastructure rearchitecture. He didn’t start drawing boxes and arrows, and he didn’t give me a list of “it depends” scenarios.

He asked a direct question: “What growth are we assuming in the next few years? 2x, 5x, or 20x?”

Then he laid out the reality, with absolute, ruthless clarity:

• If we plan to scale 2x-5x: We don’t have to do anything. We just keep going and maintain the current infrastructure.

• If we anticipate 10x-100x growth: Our current infra will collapse. The costs will skyrocket to X. We will hit hard database limitations, like MongoDB’s 16MB document limit. Here is exactly where we are duplicating data unnecessarily, and here is the architecture that will cut our running costs by 20-50%.

There was no “it depends.” There was pure math, clear options, calculated risks, and hypotheses he was taking absolute responsibility for.

Next time you are asked for a technical direction, use this exact framework. Bring exactly two options to the table:

1. The Recommendation (Your Choice)

This is the path you are putting your name on.

• The Math & Telemetry: What is the specific volume this will handle? What do our current product metrics tell us this will solve?

• The Hypotheses: What are the core assumptions you are making, and how will you validate them in production?

• The Friction Erased: Exactly which bottlenecks (technical or user-facing) are removed?

• The Concrete Risks: What will inevitably break, cost money, or hit a hard limit at scale?

2. The Alternative (The Fallback)

This is the viable second path, presented solely to frame the concrete trade-offs of the first.

• The Distinction: How this fundamentally differs from your recommendation in terms of architecture or product capability.

• The Costs & Opportunities: The exact difference in time, capital, and engineering hours.

• The Losses: The specific market opportunities, performance metrics, or scaling multipliers the business explicitly sacrifices if they reject your recommendation.

That is it. You lay out the map, point to the destination, and highlight the cliffs with cold, hard numbers.

Your job as an engineering leader is not to map out every single blade of grass in the valley of possibilities. Your job is to lead your team and your stakeholders through it. To make the decision. To clear the fog.

Take the damn responsibility for it.

Need some inspiration?

Have a look at:

• The Problem Solving Framework

• How to Be Data Driven Engineering Leader

• Engineering Strategy Framework (esp. Proximate Objectives)

• The Product Engineering Manifesto

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

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