Explaining your product to everyone at once feels efficient and transparent. In practice, it is one of the fastest ways to make sure no one actually understands what you mean.

We like the idea of a single story that works for everyone — users, stakeholders, engineers, leadership, partners. It sounds clean and professional. It rarely survives contact with reality.

These groups are not just different people. They think in different systems. Each listens for something else, filters information differently, and decides based on different signals. When you give them the same message, they do not align. They reinterpret.

That reinterpretation is where most product communication quietly breaks.

You launch a feature and write a careful explanation. You cover the user problem, business value, technical constraints, and some vision. It feels complete, so you share it widely.

Users ignore most of it. They want to know what changes for them right now. Stakeholders ask follow-up questions to assess risk and defend the decision. The team starts building but interprets the goal differently. Management scans, jumps to conclusions, and moves on. Partners miss how this connects to their systems.

Nothing dramatic happens. Alignment is lost.

The usual reaction is to say we need to communicate better. In practice, the problem is not clarity. It is targeting.

Good product storytelling is not about simplifying one message for everyone. It is about shaping different versions so each audience gets what they need.

Users are not interested in your reasoning. They want to see their situation reflected and understand how the product changes it. The moment you move from showing value to explaining context, you lose them. They are not judging your thinking. They are judging whether this makes their life easier, faster, or safer.

Stakeholders are not trying to use the product. They are trying to justify decisions. They need a story that holds up under pressure and can be repeated when challenged. Timing, alternatives, and evidence matter. If your story cannot be defended in a budget or prioritization discussion, it does not work for them.

Inside the team, the problem changes. Storytelling is not about persuasion. It is about precision. Vague goals create expensive misunderstandings. Phrases like ‘improve engagement’ or ‘enhance user experience’ do not align a team. They create space for multiple interpretations. A strong internal story removes ambiguity and makes success observable. If people describe the goal differently, the story has already failed.

Management looks for something else. Features matter less than the quality of decisions. They are evaluating how you handle trade-offs, assess risk, and prioritize under constraints. A story that only talks about opportunity and ignores what you are not doing or what could go wrong sounds incomplete. Clarity about limits builds more trust than optimism.

With partners, the gap is operational. They do not need your intent or reasoning. They need to know how things connect: what goes in, what comes out, who is responsible, and where the boundaries are. If that is not clear, they fill the gaps with their own assumptions. What you later call integration complexity is often just unclear communication.

Most teams ignore one audience: the future version of the organization. Months later, people change, context disappears, and decisions that once felt obvious become opaque. Someone asks why a certain approach was chosen, and the only answer is ‘it made sense at the time.’ At that point, the story was never told. What is missing is not the record of what was done, but the reasoning behind it — the constraints, alternatives, and trade-offs that shaped the decision.

Step back and a pattern appears. The product does not change. The facts stay the same. What changes is the question each audience is trying to answer. Users ask what this does for them. Stakeholders ask if it is worth it. The team asks what needs to be built. Management asks if this is the right call in context. Partners ask how to connect to it. The future organization asks why it ended up this way.

Trying to answer all these questions at once leads to messages that feel complete but land nowhere. They contain everything and emphasize nothing.

A more effective approach is less elegant and more precise. Before communicating, decide which audience you are addressing and what decision you expect from them. Shape the story around that decision, even if it means leaving other aspects aside.

This is where product communication gets uncomfortable. It stops being about covering everything and starts being about being selective.

You do not need a better, more polished, or more inspiring story. You need to aim it.

At this point, the “remote vs. office” debate feels less like a strategy discussion and more like a ritual. Leaders defend office presence as discipline. Employees defend remote work as freedom. Both sides are convinced they are protecting productivity.

In reality, most are protecting something else: their own comfort with how work used to be.

If a company needs people in the office to feel in control, the issue is not remote work. It is a lack of trust, clarity, and measurable outcomes. Office attendance does not solve that.

The myths we keep repeating

Let’s start with a few ideas that sound reasonable but don’t hold up well under scrutiny.

Remote work is often framed as a reward you earn. In practice, flexible work reduces attrition but leaves performance mostly unchanged. So remote work is less a perk, more a retention tool.

Presence is often equated with productivity. It is not. Presence gives visibility, and visibility is easier to measure than output.

There is also the claim that the office is only for brainstorming. That is only part of the story. In-person work also builds informal networks, speeds up onboarding, and supports mentorship. These are the invisible systems that keep organizations running.

Where remote work actually breaks

Remote work does not fail randomly. It fails predictably.

Remote work struggles when tasks are ambiguous, when tight coordination is needed, when knowledge is informal, or when fast feedback is required. It also fails where learning depends on observation instead of clear instruction.

You see this in collaboration patterns. Remote teams become more siloed. Cross-team interactions drop. People work more with their immediate group and less across the company.

Innovation drops when coordination is weak. Not because people are less creative at home, but because spontaneous exchange is less likely.

But when work is structured, measurable, and needs long focus, remote often matches or beats the office. Fewer interruptions. More control. Less performance theater.

The hidden costs of hybrid

Hybrid is sold as a compromise. In reality, it often combines the downsides of both models.

Uncoordinated office days mean empty offices or people commuting just to join video calls. Communication overhead grows. Meetings multiply. Calendars fragment.

Mentorship suffers quietly. Seniors spend less time transferring knowledge. Juniors lose informal learning. The cost shows up later.

Decision-making also suffers. Without clear rules, frustration grows. People see decisions as arbitrary.

Stop choosing. Start designing.

The more useful framing is simple: work is not one thing. It is a set of activities with different requirements.

Some tasks need deep focus and independence. Others need high-bandwidth interaction. Treating them the same, and putting them in the same environment, is where most organizations fail.

A more effective model looks like this:

• Remote is the default for execution. Clear tasks, defined outputs, measurable outcomes.

• Office presence is triggered by the work, not mandated. You come together when needed: ambiguity, cross-team alignment, onboarding, complex feedback.

When you come together, it is intentional and synchronized. Not optional attendance scattered through the week.

Replace presence with evidence

The final shift is uncomfortable but necessary.

Modern work cannot be managed by observation. It needs to be managed by signals.

Cycle time. Decision speed. Error rates. Time to onboard new hires. Retention.

These are harder to measure than attendance. But they are also harder to fake.

Once leaders trust these signals, the urge to see people working fades. So does much of the anxiety behind return-to-office mandates.

The actual deal

Remote work is not a privilege. It is also not a free-for-all.

The workable model is a simple trade:

• Freedom by default.

• Structure by necessity.

Not ideology. Not control. Design. And not the idea that a chair in an office is a performance system.

Every few weeks, a new wave of headlines arrives with a familiar message: AI is taking over journalism. Somewhere between conference slides, LinkedIn posts, and media think pieces, a number appears — 5%, 10%, sometimes much higher — suggesting that a growing share of news content is now written “by AI” or “with AI.”

It sounds dramatic. It is meant to sound dramatic.

The implied image is almost cinematic: invisible systems drafting articles at scale, quietly replacing human writers, reshaping the very idea of journalism. A reader scrolling through news feeds might reasonably assume that somewhere along the line, the byline has become… optional.

And yet, if you step inside an actual newsroom, the picture looks very different. Not less interesting — just less theatrical.

AI is indeed entering editorial processes at speed. But it is not marching through the front door, announcing itself as the new author of record. It is slipping in through side entrances — tools, assistants, small utilities — embedding itself into workflows in ways that are often invisible both to readers and, sometimes, even to the people describing them publicly.

Which raises a more precise question: when we say “AI is used in the newsroom,” what are we actually talking about?

What “using AI in the newsroom” actually means

The phrase AI-generated journalism suggests a binary reality: either a human wrote the article, or a machine did. In practice, the situation is far more nuanced and far more layered.

At one extreme, there are fully automated articles. These exist, but they tend to live in highly structured environments: sports results, financial earnings, weather updates, or election data. In these cases, the “article” is essentially a transformation of structured data into readable text. This is not new — variations of this have existed for years, long before the current generation of large language models.

At the other end of the spectrum is something much more common, but much harder to label.

A journalist writes a story, but uses AI to generate five headline options and selects one. Another journalist feeds a long interview transcript into a tool to extract key quotes. An editor asks AI to shorten a paragraph, adjust tone, or produce a summary for social media. A producer uses it to translate material or suggest alternative framing for a lead.

None of these scenarios fit neatly into “AI wrote the article.” Yet all of them are part of the editorial process.

This creates a wide, almost elastic definition of AI usage. The same newsroom might claim both “we don’t use AI to write articles” and “AI is deeply integrated into our workflow” — and both statements would be true.

Which is why the discussion about percentages often feels misleading. It compresses a spectrum into a single number.

To understand what is actually changing, it is more useful to look not at how much content AI writes, but at where in the process AI is most effective.

The tasks AI automates first — and why

AI does not begin by taking over the most visible or prestigious parts of journalism. It begins with the work that journalists themselves would gladly spend less time doing.

Transcribing interviews that stretch over hours. Translating material from one language to another. Condensing long reports into usable summaries. Generating multiple headline options under time pressure. Cleaning up grammar, tightening structure, shortening text without losing meaning.

These tasks are not trivial, but they are procedural. They require effort, time, and attention — but not necessarily deep editorial judgment.

And that distinction matters.

AI performs best where the output can be quickly evaluated by a human. A headline can be judged in seconds. A summary can be compared to the source. A transcript can be verified against audio. The human remains firmly in control, but the machine accelerates the process.

By contrast, tasks that require interpretation, contextual understanding, and accountability — deciding what the story is, which facts matter, how they should be framed — remain much more resistant to automation.

AI enters the newsroom not by replacing judgment, but by reducing friction. It removes the small delays that accumulate across the workflow — the minutes that become hours, the hours that become days.

And once those delays begin to disappear, something else happens. AI starts to spread into places where its presence is less obvious.

Where AI is used quietly

The most interesting part of AI adoption in journalism is not where it is visible. It is where it is not.

Public discussions tend to focus on the idea of AI writing articles. Inside newsrooms, much of the real impact happens earlier (and later) in the process.

Before a single line is written, AI may already be involved. It can help navigate large document sets, extract key points from reports, identify patterns across sources, or surface relevant material from archives. For investigative work, this is particularly valuable: not as a source of truth, but as a way to reduce the time needed to find where truth might be hiding.

None of this appears in the final publication. The reader never sees the hours saved. After the article is written, another layer of quiet activity begins.

A single piece of journalism rarely lives as a single piece anymore. It needs to be adapted — for search, for mobile, for social media, for newsletters, for different audience segments. Each of these requires slightly different wording, structure, or emphasis.

This is where AI is extremely efficient.

It can generate variations quickly, test different angles, produce summaries of different lengths, and adapt tone depending on the channel. Again, the journalist remains responsible for the content — but the distribution layer becomes increasingly assisted.

In effect, AI is not just participating in journalism. It is participating in how journalism moves.

What the real AI workflow in major newsrooms looks like

If you strip away the narratives and look at how large news organizations actually operate today, the workflow is less revolutionary than evolutionary.

The core remains intact. A journalist investigates, interviews, verifies, and writes. An editor reviews, challenges, refines. Accountability sits with people, not systems.

Around this core, however, a new layer has formed.

During research, AI may assist in processing documents or transcripts. During writing, it may offer structural suggestions or alternative phrasings. After writing, it contributes to headlines, summaries, and distribution formats. Throughout the process, it acts as a tool — sometimes helpful, sometimes ignored, occasionally wrong.

Importantly, it is rarely autonomous.

The idea that AI writes an article and a human simply approves it is not how most serious newsrooms operate. The direction is usually the opposite: a human creates the material, and AI supports specific steps around it.

This distinction may seem subtle, but it is fundamental. It defines whether AI is an author or an instrument.

For now, in most traditional news organizations, it is very clearly the latter.

A few conclusions

So how deeply is AI embedded in journalism?

Deep enough to matter. Not deep enough to replace it.

The more accurate picture is not one of sudden disruption, but of gradual integration. AI is becoming part of the infrastructure of news production: accelerating research, simplifying editing, enabling faster and more flexible distribution.

At the same time, the boundaries are holding. The closer we get to the core of journalism — facts, interpretation, accountability — the more cautious newsrooms remain.

This creates an interesting tension.

From the outside, it looks like AI is writing the news. From the inside, it feels more like AI is reorganizing the work around the news.

And perhaps that is the more useful way to think about it.

Journalism is not being replaced. It is being restructured — one quiet workflow improvement at a time.

Most product and engineering teams have people who fall into one of two groups.

The first group treats every stakeholder request as an order. A new feature? Yes. A last-minute change? Yes. Another urgent request from another department? Yes again. Calendars fill up, roadmaps get longer, and teams quietly work evenings and weekends to keep all the promises. The Yes-Man seems helpful and flexible, but eventually, deadlines slip, the team burns out, and everyone wonders who approved it all.

The second group is the opposite. Every request gets pushback. “Not in the roadmap.” “No resources.” “Come back next quarter.” Sometimes it’s just a polite no. Mister No protects the team from overload, but over time, stakeholders stop sharing ideas, innovation slows, and the product team starts to seem more like a gatekeeper than a partner.

Both attitudes make sense. One focuses on keeping stakeholders happy. The other focuses on stability and control. But both avoid the same uncomfortable task: negotiation.

The real job of product leadership isn’t just saying yes or no. It’s turning requests into priority decisions.

When someone asks for a new feature, the honest answer is rarely just yes or no. It’s usually something like, “Yes, if we move something else out of the plan,” or, “Yes, but that will push the analytics work back by three weeks.” The conversation shifts from approval to discussing trade-offs.

This is when priorities become real. When requests are considered alone, everything seems important. Every idea feels urgent by itself. But once you compare it to other planned work, the question changes from “Is this useful?” to “Is this more important than what we’re already doing?”

And that’s a much harder question to answer.

In practice, good teams make trade-offs clear as soon as possible. They show the roadmap, the backlog, and what the team is working on, along with available capacity. Instead of saying, “we’ll try to fit it in,” they explain each request in terms of time, effort, and impact. This isn’t to block ideas, but to bring clarity to the conversation.

At this point, something interesting often happens. Many requests get smaller. A “must-have feature” becomes “maybe a smaller version would work.” An urgent request turns into “maybe next quarter is fine.” Sometimes, two stakeholders realize they’re competing for the same resources and start negotiating with each other instead of pushing the team.

In other words, being transparent does half the negotiating for you.

Another key point is to separate ideas from commitments. Product teams should welcome ideas, but making commitments should be much harder. Anyone can suggest something new, but deciding to build it should follow the same prioritization process as everything else. This keeps the team from making accidental promises that turn into obligations.

This approach also takes much of the emotion out of these conversations. If a team just says “no,” the discussion feels personal and stakeholders feel rejected. If a team says “yes” but sacrifices its own capacity, resentment builds within the team.

But when the answer is, “here are the trade-offs,” the decision is no longer personal. It becomes about structure. The conversation shifts from asking for permission to discussing how to allocate resources.

Interestingly, many requests disappear once trade-offs are clear. When stakeholders see that their urgent feature would delay something else they care about, priorities become clear much faster.

Good product teams work differently. Instead of making promises or refusing requests, they set conditions. Every request goes through the same process: what’s the impact, what’s the effort, and what needs to be postponed to make room for it.

This approach has an unexpected benefit. Stakeholders start negotiating with each other instead of with the team, which is usually a much healthier dynamic.

So next time someone asks your team for something new, try not to be a Yes-Man. Also, avoid becoming Mister No.

Try something a bit more uncomfortable. Say, “Yes, we can do this. Let’s decide together what will no longer be a priority.”

At some point in every leadership role, you realize that your job is not to produce results. It is to translate reality.

Roadmaps, OKRs, and delivery plans are just tools. The real work often happens in more personal moments, like when you stand in front of your team, open a Zoom call, or write a Slack message and decide how to share the news:

• We won

• We lost

• We don’t know yet

How well you communicate shapes more than just morale. It affects trust, alignment, and long-term results. I have seen strong strategies fail because of poor communication, and average strategies succeed when the message was clear and consistent.

Most teams do not fail because of poor strategy. They fall apart because of mixed messages, such as excessive optimism, delayed candor, or silence when people need clarity.

Let’s talk about the good, the bad, and the ugly.

The Good

Good news looks easy. It rarely is.

A feature performs better than expected. Traffic grows. Leadership approves budget. A difficult project lands well with users. The numbers look good. The mood lifts.

The risk here is subtle.

Some leaders minimize success in the name of discipline: “Great, but let’s not celebrate too much.” The intention is focus. The effect is emotional flatness. Over time, people stop feeling that their work matters.

Some leaders exaggerate success. Every small win is called “a game changer.” Every milestone is “transformational.” This can feel exciting at first, but when reality sets in, people lose trust.

Good news is not about excitement. It is about pattern recognition.

If you share success without explaining why it happened, you are not leading. You are just reporting. And reporting is neutral. Leadership is interpretive.

• What exactly worked?

• Was it timing?

• Was it positioning?

• Was it cross-functional collaboration?

• Was it a risky decision that paid off?

Good news should make it clear which actions are worth repeating. It should help the team understand what success looks like. Credit should be given specifically, not just with a vague “great job, everyone.” Clear recognition builds pride and sets standards.

Celebration is useful. But reinforcement is strategic. Good news can boost energy if you handle it with discipline.

The Bad

Bad news is where leadership maturity becomes visible.

A deadline slips. A release underperforms. A budget is reduced. A strategic direction changes. A restructuring is announced.

There are predictable failure modes.

The first problem is the delay. Leaders hope the issue will go away or become less important, but that rarely happens. In the meantime, uncertainty spreads through the team.

The second problem is dilution. Leaders use soft language like “some challenges,” “temporary adjustments,” or “minor recalibration.” People pick up on the tone and sense something is wrong, but they cannot see the real problem. This makes anxiety grow.

The third problem is delegation. Leaders pass difficult messages down the chain. A manager might ask a team lead to share news that really came from above. The information may be accurate, but it does not feel like the right person is taking responsibility.

Bad news does not require drama. It requires structure.

• Here are the facts.

• Here are the constraints.

• Here is what we are doing.

• Here is what this means for you.

• Here is what remains uncertain.

Clarity reduces anxiety. Vagueness amplifies it.

Teams are surprisingly resilient when reality is explicit. What they struggle with is ambiguity disguised as comfort.

I have learned that the sooner you share bad news with context, the sooner your team can regain stability. If you stay silent, people create their own stories, and those stories are rarely positive.

Bad news, handled properly, builds credibility. It signals that you are not curating reality. You are sharing it.

The Ugly

The most complex category is neither success nor failure.

It is uncertainty.

Funding is under review. Strategic options are being considered. There are outside pressures that might affect your department. The market may be shifting, but it is not clear yet. A product experiment could change priorities or simply fade away.

This is where many leaders freeze.

Leaders worry about saying too much and being wrong later, so they say nothing. Sometimes they try to reassure the team too soon by saying, “Everything is fine.” But teams notice when something is off. They pick up on tension, see the signs, and read between the lines.

Uncertainty does not scare professionals. Lack of framing does.

The discipline here is subtle.

• Define what is known.

• Define what is not known.

• Set the next checkpoint, which is when you expect to have more clarity.

You do not need certainty. You need boundaries.

Sometimes the most powerful thing a leader can say is: “I don’t know yet. Here is what we are monitoring. Here is when we will revisit this.”

Authority is not built on omniscience. It is built on composure in ambiguity.

When uncertainty is acknowledged, teams can calibrate emotionally. When it is hidden, it grows in the shadows and turns into a rumor.

In my experience, unclear situations are when trust is either built or lost for good. In these moments, people pay more attention to what you do than what you say.

Sharing news is not a soft skill. It is a strategic one.

• Good news should reinforce what works.

• Bad news should clarify direction.

• Unclear news should define reality.

If you reflect honestly on your own leadership, which category do you handle worst?

• Is it the good news, because you move on too quickly?

• Is it the bad news, because you put it off?

• Or is it the ugly news, because uncertainty makes you uneasy?

The answer is usually personal. And rarely visible in a dashboard.

But your team always knows.

I believe in sticking to a clear work routine. Arrive on time, leave on time, respect weekends, and take your vacations. People with families, hobbies, and health concerns need this kind of structure.

But even so, I constantly catch myself checking email in the evening. Replying on Saturday. Clarifying something small during vacation. Not because someone demands it. Not because management pressures me. But because of a quiet internal calculation: “It is easier to fix this now than to deal with the consequences on Monday.”

Spending five minutes today can save two hours of trouble tomorrow. A quick answer can stop misunderstandings, and a fast decision can help others move forward. Operationally, this logic makes sense.

But this is where the trap starts.

When a few people keep acting this way, they slowly change what’s normal. Management notices quick responses, deadlines met, and problems avoided. The system looks efficient. But the hidden cost — personal time used to cover planning gaps — goes unnoticed.

Soon, weekend replies stop being rare and just become part of the routine. Someone who waits until Monday to respond might seem “less engaged.” The person who says, “I will finalize this over the weekend (despite a sick child at home),” starts to look like a quiet hero. It’s not officially required, but it’s quietly admired.

Hero culture is tempting. It feels productive, responsible, and grown-up. But often, it hides bigger problems like unrealistic planning, unclear priorities, not enough staff, poor delegation, or indecision from managers.

If deadlines are always saved by late-night work, the organization never learns to plan well. If getting things done depends on extra hours, the system doesn’t have enough resources. It just hasn’t realized it yet.

The hard truth is that many of us choose to take part in this cycle. It’s not because we’re afraid, but because we want to be efficient, professional, and believe that small actions now will stop bigger problems later.

And often, that’s true.

But lasting success doesn’t come from good intentions. It comes from setting clear boundaries.

I’m not saying we should become strict clock-watchers. Emergencies will happen. Product launches need extra effort. Sometimes, big problems mean late nights. Taking ownership is part of being a leader.

The real question is: are we just handling exceptions, or are we making them the new normal?

• If working on weekends is rare, it shows something urgent is happening.

• If weekend work becomes routine, it’s a sign that something is wrong.

Leaving the office on time isn’t lazy. It forces the organization to set better priorities, plan more realistically, and make real trade-offs instead of quietly taking up your personal time.

Still, next Saturday, I’ll probably check my inbox again.

This tension is real. The system rewards quick responses. I know that spending five minutes now can prevent a bigger mess later. But I also know that every small fix makes it more likely people will expect me to always step in.

Leadership isn’t just about fixing problems. It’s also about knowing which ones can wait.

The toughest boundary to set is the one with yourself.

Recently, I have heard people describe the future of work in dramatic terms. They say companies will soon have to choose between ‘expensive but productive AI’ and ‘cheap but slow humans.’ This idea is presented like a simple business decision: replace payroll with computers, swap salaries for hardware, and focus on efficiency.

This argument sounds convincing because it turns a complicated change into a simple choice. But the real situation is less dramatic. The best AI systems are not cheap. Advanced models use a lot of computing power. AI agents run many processes, use tools, and take time to reach results. Data centers and energy are limited. The most powerful AI is also often expensive to run. So, the choice is not just ‘AI is cheaper than humans.’ In many cases, it is ‘AI is more powerful, but not always cheaper.’

The real issue is not simply swapping expensive people for cheaper machines. It is about leverage. AI changes how much work one person can do, how much complexity a role can handle, and how much authority is needed for decisions.

So, instead of asking if AI will replace people, we should ask: which roles gain leverage as AI gets better, and which ones lose it?

The Real Situation: Human LeverageHuman LeverageHuman Leverage Quadrant

If we look beyond the headlines and think more broadly, we can map job roles using two simple factors.

The first factor is automation pressure, shown on the horizontal axis. This measures how structured and easy to measure the work is. If a task can be clearly defined, checked, and repeated, it can eventually be automated.

The second factor is human leverage, shown on the vertical axis. This shows how much decision-making, handling of uncertainty, and responsibility a role has. Jobs high on this axis do more than just complete tasks. They make choices, work with incomplete information, and face real consequences.

When we look at roles using these two factors, things become clearer.

In the bottom-right area, we find data entry clerks, scripted support jobs, and other routine roles. These jobs are in very structured settings and have little authority. It is not about intelligence. These roles just face the most automation pressure. As AI gets better, the value of repetitive work goes down.

In the top-left area, there are strategy leaders, senior product managers, and managing editors — people whose jobs mix uncertainty with decision-making power. These roles are not immune to AI, but they are harder to replace. AI can help with analysis, drafts, and simulations, but it cannot take on full responsibility or handle the politics of big decisions.

The most interesting area is the top-right, called the AI Leverage Zone. Here, we see product analysts, designers who use AI, and engineers who go beyond routine work. These jobs are structured but also have real influence. As AI gets better, these roles do not go away. Instead, they grow and use AI as a tool, rather than competing with it.

This is the key change. AI does not reward just intelligence. It rewards leverage. If your job is mostly about following set steps, AI will compete with you. If your job is about making decisions and setting direction, AI will help you do more.

This is a very different story from ‘AI versus humans.’ It is really ‘AI versus low-leverage work.’

Role Movement Under Increasing AI Capability

Now we reach the more complex and sometimes uncomfortable part. Job roles are not fixed points on a chart. They change over time.

As AI gets better, routine jobs tend to move lower and further right on the chart. These roles lose authority and face more automation pressure. This is not about right or wrong — it is about economics. When machines can do the same work at scale, the value of repetitive tasks drops.

Middle roles that mostly coordinate or pass along information, but lack real decision-making power, are also at risk. If a job is mainly about moving information between people or systems, AI will start to take over that work. Unless these roles gain more authority or strategic value, they will lose ground.

At the same time, roles that use AI effectively tend to move up. Engineers who build AI into systems become more influential. Analysts who manage AI models, instead of just making spreadsheets, become more valuable. Designers who guide AI tools, rather than creating everything by hand, increase both their output and their importance.

Even the top-left area shifts a bit to the right over time. Leaders who ignore AI risk losing their influence. Authority without technical skills slowly becomes just a title. The leaders who last will use AI in their decisions but still rely on their own judgment.

At this stage, a troubling pattern shows up. In the diagram, arrows in the top half mostly point upward, while those in the bottom half point downward. It seems like a story of growing inequality, with the successful gaining even more.

But this outcome depends on whether people and organizations can move up.

If people and organizations make it possible to move up, if structured roles gain AI skills and more decision-making power, then this model shows progress, not division. But if there is little mobility, then inequality will grow.

AI does not get rid of all jobs at once. It first removes low-leverage, internal roles. What is left are jobs that require higher-level judgment or very basic execution.

So the real question for all of us is not whether AI is coming. It is already here.

The question is both simple and challenging: Are we moving up in leverage faster than AI is improving in capability?

That is the real competition.

If you lead a product or engineering team, you have experienced this.

The organization runs smoothly. The newsroom publishes quickly. Deadlines are met, distribution grows, and nothing crashes during busy times. The system works.

No one mentions it.

But when something goes wrong — a story in the wrong section, a field filled out wrong, a workflow skipped, or a feature misunderstood — the reaction is quick and certain: “The technology failed.”

You realize it is not just about one incident. It is about a pattern.

In many organizations, especially mission-driven ones, product and engineering teams exist in a strange place. When things work, they are considered normal. When something fails, it becomes evidence.

Reliability has a strange effect: it makes itself invisible. The more stable your platform is, the less people notice it. Hundreds of successful publishing cycles seem ordinary. Smooth teamwork across regions is expected. High-traffic events without downtime feel routine. But none of this is actually routine. It is the result of architecture, infrastructure, and careful design decisions made years ago to prevent problems people no longer remember.

Still, reliability is rarely celebrated. People just assume it.

People remember the one failure, not the thousands of problems that were prevented.

There is also a more uncomfortable layer. When users ignore defined workflows, resist tools, misuse permissions, or simply choose convenience over process, it is often easier to blame the system than to confront behavior. Technology becomes the safest target. It does not argue. It does not feel offended. It does not escalate politically.

A subtle but powerful story takes hold: “If the system were designed properly, this wouldn’t have happened.”

There is some truth to this. Good design makes things easier. Strong user experience prevents many mistakes. Permissions and guardrails are important. But expecting technology to fully make up for human behavior is both comforting and unrealistic.

No road system can stop all reckless driving. No email client can prevent every message from going to the wrong person. No CMS can remove all judgment errors or rule-breaking. Technology can guide, but it cannot replace accountability.

If we do not clearly separate these issues, everything gets called a “tech” problem. When that happens, accountability becomes unclear, and the product team ends up bearing all the operational burden.

One simple change can shift the conversation: name the categories. When something goes wrong, separate platform defects from training gaps and from governance violations. Engineering owns defects. Knowledge gaps need training and support. Process violations need managers to step in. These distinctions are not about blame — they are about structure. Without them, stories become the main way people judge what happened.

There is another truth product leaders need to face. Being underappreciated is not always about unfairness. Sometimes it happens because your work isn’t being translated.

If you talk about your work in terms of tickets completed, refactoring, or infrastructure, but leadership cares about mission impact, audience reach, editorial speed, and risk, you are speaking different languages. Stability seems basic unless you show its impact. Saying “We optimized workflows” sounds technical, but “We reduced customer preparation time by nearly twenty percent” sounds strategic.

If you do not link the architecture to the mission, people stop noticing the architecture.

Product leadership also has a political side that many people do not like to talk about. In complex organizations, part of your job is to help people understand what causes problems. You need to define what counts as a system failure and what is a behavior issue. Make trade-offs clear before something goes wrong. Show the value of risk reduction, even if no one asked for it. If you only show up after things go wrong, people will link you to failures. But if you regularly explain how the platform supports the organization’s goals, you start to be seen as a strategic partner, not just a service provider.

Of course, not every organization just misunderstands technology. In some places, technology is always seen as a cost rather than as something that adds value. In these cases, better reporting will not change how people see it. The issue is not about being seen — it is about how people think.

This leads to a tougher, more personal question. Are you in a place that can change how it sees product work, or will it always treat infrastructure as something in the background?

This question matters because cultural debt builds up quietly. If your team keeps getting blamed for things they cannot control, morale drops long before you see it in the numbers. You can fix technical debt with time and money, but cultural debt grows quietly and is harder to fix.

Product leadership is not just about launching features or keeping systems stable. It is also about making sure everyone is clear on what the system does, what people are responsible for, and where accountability lies. If we do not set that clarity ourselves, someone else will do it for us.

And their version of clarity may not be generous.

Most project pain doesn’t show up with chaos or obvious mistakes. Instead, it comes quietly, as a familiar heaviness: another deadline that feels tight for no clear reason, another scope discussion that changes nothing, another delivery where everyone worked hard but still leaves tired and vaguely dissatisfied.

This is usually when people start blaming execution, communication, or alignment. Sometimes they blame the market or “the reality we’re in.” Almost never the real cause.

If this sounds familiar, it matters for a simple reason: this kind of pain builds up. It slowly eats away at credibility, energy, and trust until you only notice it when it feels normal.

Most of us have seen this pattern. A project starts with ambition and optimism. The scope is important, maybe even strategic. The deadline matters, often for outside reasons. The team is strong but “lean for now.” Everyone nods, understands the constraints, and agrees to “stay flexible.”

Yet somehow, all three sides of the triangle — scope, time, and resources — end up treated as non-negotiable.

This is where the trouble starts.

We often talk about the classic project triangle as something to balance. It sounds reasonable and professional. But balance is a comforting word that hides a hard truth: trade-offs aren’t balanced, they’re chosen or avoided. Avoiding them is still a choice; it just delays the cost.

I call this the Triangle of Sadness. Not because constraints are bad, but because pretending they don’t hurt is worse. The sadness isn’t in the triangle itself. It’s in the group decision to act as if commitment has no cost.

That’s why “marriage” is a better metaphor than “balance.” Marriage means exclusivity. If you marry scope, speed will suffer. If you marry time, ambition must narrow. If you marry fixed resources, you accept limits on both scope and pace. Any of these marriages can work, but you can’t secretly marry all three and hope no one notices.

What actually happens when we try is predictable. Scope quietly becomes tougher. Deadlines turn emotional instead of rational. Teams work harder. Quality slips. Temporary fixes become permanent. Heroics are praised. Fatigue becomes normal. Later, the project is called “challenging, but successful.”

This is usually when teams get blamed for not pushing back enough. That’s convenient, but mostly wrong. Teams don’t break the triangle. Organizations do, when they push unresolved trade-offs down and call it empowerment.

The real failure here isn’t delivery. It’s owning the decisions.

Someone, somewhere, wants certainty without paying for it. Leadership wants confidence. Product is asked to handle ambiguity. Delivery pays the price. Everyone stays polite. No one says the trade-off out loud. And when the project hurts, the triangle quietly makes the choice for you.

This keeps happening because the incentives are subtle. Optimism gets rewarded. Saying “we’ll figure it out” feels helpful. Naming trade-offs feels political. Ambiguity buys time until it gets expensive. By the time pain is obvious, it’s already seen as an execution problem, not a decision problem.

The irony is that none of this is new. The triangle isn’t a secret. Everyone knows about it. What’s rare is treating it as a real moment of truth, not just a diagram in a slide deck.

A project isn’t healthy just because it delivers everything on time with limited resources. That’s a slogan, not a strategy. A project is healthy when everyone can clearly say which side of the triangle was chosen, why, and by whom, and accept the consequences without surprise.

That kind of clarity doesn’t remove tension. It removes confusion. And confusion costs much more.

So here’s the uncomfortable question I keep asking: when your last project hurt, could everyone clearly name the trade-off that was made? Or did the Triangle of Sadness quietly decide for you while everyone stayed busy?

Because the triangle never goes away. It just waits until someone is honest enough to face it.

“Never let a good crisis go to waste” is often linked to Winston Churchill, though historians note he may not have said it exactly that way. Whether he did or not hardly matters. The phrase sticks because it’s true: crises change the rules. What seemed impossible yesterday can suddenly become possible, urgent, or even obvious.

In politics, people often view this idea with suspicion. A crisis can be used as an excuse to make decisions that would not pass in normal times. That view is not wrong. But in companies, products, and teams, the idea is less dramatic and much more practical.

Usually, organizations value stability above all. Roadmaps are treated as untouchable, and backlogs are managed with great care. Processes are protected like family traditions. People may agree something is broken, but it never seems urgent enough to fix. Then a crisis hits. Revenue falls, users leave, a platform policy changes, a regulator steps in, or a competitor makes a smart move. Suddenly, the same people who said “we can’t touch this” start asking, “what if we rebuild it completely?”

This is when product management proves its value.

A crisis makes priorities clear. Features that seemed “strategic” last quarter are revealed as unnecessary. Metrics that were once ignored can no longer be overlooked. Meetings get shorter, not because people improved, but because time now matters. In a crisis, the organization stops pretending to be perfect and shows its true nature: a group of people trying to get through tough times.

For product teams, this is both uncomfortable and powerful. Many decisions that were delayed finally get made. Old features that stayed only because “someone important once asked for them” are now questioned. Technical debt, once ignored, is now seen as a real problem. The crisis allows people to speak openly about issues that were only mentioned quietly before.

Of course, not every crisis leads to good results. Some teams freeze, some panic, and others work hard on the wrong things. “Never let a good crisis go to waste” does not mean acting without a plan. It means using the time when people are open to change to do what was needed all along.

There’s another hard truth. Crises show who was really thinking and who was just following orders. Product strategies that only worked in calm times often fail right away. The ones that last are usually simple: focused on users, strict about value, and careful with metrics. A crisis doesn’t create good product thinking, but it does take away the excuses that hide its absence.

Here’s the final irony. After a crisis ends, organizations quickly forget. Old habits come back. Emergency decisions become “temporary solutions” that last for years. The clarity disappears faster than expected. The real waste is not failing during a crisis, but surviving it and then acting as if nothing changed.

If a crisis happens, whether big or small, inside or outside the company, the worst thing to do is treat it only as a problem to fix. It’s also a chance for focus, leverage, and honesty. It’s painful and stressful, but it’s also a rare moment of truth.

In product management, honesty is rare. When it appears, it should not be wasted.

Let’s talk about KPIs. We may not love them, but they are always part of the conversation.

I like the term ‘perverse incentives.’ It may sound academic, but the idea is simple. You try to fix a problem by introducing a KPI. People follow the KPI exactly, but the problem actually gets worse.

A classic example is the Cobra Effect. During British rule in India, officials wanted to reduce venomous snakes in Delhi. They offered a reward for every dead cobra. The goal was clear, the incentive made sense, and the plan seemed perfect.

But then locals began breeding cobras at home. When the program ended, they released the now-worthless snakes. Instead of fewer cobras, there were even more than before. The KPI was achieved, but the real goal was lost.

Most experienced product managers hear this story, nod, and think, ‘Of course.’ Then they return to work and set up a KPI that does something similar, only with better charts.

You’ve probably seen KPIs for delivery speed that teach teams to treat quality as optional. Or engagement KPIs that push for features that are addictive, like junk food. Or growth KPIs that turn users into numbers to acquire, nudge, retain, and monetize, while trust gets ignored.

This isn’t because people are foolish or have bad intentions. It happens because KPIs are strong tools that influence behavior. They don’t just measure what’s happening — they change it. People focus on what you measure, not what you actually want.

The risky part is that KPIs seem objective and scientific. They fit neatly into dashboards and reports. Even when things go wrong, the numbers can look good for a long time. Velocity, output, and adoption may rise, but underneath, complexity, fatigue, and resentment can also grow — though those rarely show up in charts.

In product management, people often say, ‘what gets measured gets managed.’ But that’s only partly true. What gets measured gets optimized. If you optimize without good judgment, you risk creating your own cobra problem.

The hard truth is that many important product signals are difficult to measure with simple KPIs. Things like user trust, editorial integrity, long-term maintainability, and the difference between ‘people clicked’ and ‘people benefited’ are real, even if your dashboard can’t track them.

As a product leader, your job isn’t to ignore KPIs, but to keep questioning them. What behavior does this KPI encourage? What shortcuts might it allow? What would a smart, motivated team do if this number became their top priority?

If you can’t answer those questions, you’re not really managing performance. You’re running a cobra farm.

And sooner or later, the snakes will get out.

In every product role, someone eventually says, “Let’s do more research to be safe.”

It sounds responsible and mature, like something a good product manager should say. Sometimes, it’s the right move. But just as often, this is how decisions quietly die, buried under interviews, dashboards, and polished slides that change nothing.

This is where the idea of Expected Value of Information (EVI) helps, even if you never use the term in a meeting.

EVI is a simple idea. Information isn’t valuable by default; it only matters if it improves a decision. More specifically, it’s valuable if the expected improvement in outcomes is greater than the cost of getting that information, including time, money, and delays.

In product management, this matters because learning always has a cost. User interviews take time. Prototypes slow down delivery. Experiments use up engineering resources. Waiting for more data often means not shipping, not committing, and not learning from real-world feedback. EVI asks a tough question: what decision will actually change if we get this new information?

If the honest answer is “none,” then the expected value of that information is almost zero, no matter how interesting it seems.

Good product managers use EVI all the time, often without calling it that. Imagine you’re thinking about a feature that will take three months to build, but you’re not sure if users really need it. A week of interviews and a quick prototype might show the problem isn’t that big. In this case, that information could save months of work. There’s high uncertainty, a high cost if you’re wrong, and a low cost to learn — so EVI is very high. Here, research isn’t just justified; it would be irresponsible not to do it.

Now, consider a different situation. A third-party API you use is being shut down, so you have to migrate. There’s no other option. Running discovery workshops or user interviews won’t change the decision — the work has to be done. Any extra research might feel useful, but from an EVI perspective, it’s just for show. In this case, getting the work done matters more than being curious.

Prioritization is another area where EVI quietly sets strong product leaders apart from busy ones. Teams often debate whether to improve onboarding or build advanced features for power users. Both seem important. A small piece of information, like learning that 40 percent of users never finish onboarding, can completely change the roadmap. In that moment, a simple funnel analysis is extremely valuable because it changes the order of work, not just the team’s confidence.

EVI also explains why product strategy often feels slower and heavier than feature work. Strategic decisions are expensive, long-lasting, and hard to undo. Entering a new market, choosing a pricing model, or picking a core platform locks you in. The cost of being wrong is measured in years, not sprints. In these cases, even costly information can be worth it compared to the risks. A legal review, a pilot launch, or a partner conversation might seem slow, but their expected value is often very high.

Pricing decisions are a good example. Launching a new premium tier affects revenue, positioning, and trust. A fake-door test or a few tough conversations with real customers can prevent a very public mistake. When pricing goes wrong, it almost never fails quietly.

On the other end, some decisions lead teams to over-invest in learning. For example, a copy change on a low-traffic internal tool doesn’t need an experiment plan, research brief, and stakeholder review. In these cases, shipping and watching what happens is usually the smart move. The decision can be reversed, the risk is small, and the EVI of more information is close to zero.

EVI helps product teams avoid two extremes. One is analysis paralysis, where learning replaces decision-making. The other is reckless execution, where teams mistake speed for courage. EVI offers a better way: learn actively when it can change the outcome, and act quickly when it can’t.

The most useful EVI question isn’t “do we need more data?” but “what would we do differently if this turns out to be false?” If there’s no clear answer, it’s often smartest to stop researching and start shipping.

Information isn’t a virtue. Making decisions is.

For many teams, “firefighting” isn’t just a metaphor anymore. It’s what they do every day. When something breaks, a stakeholder complains, a customer is waiting, or a deadline is missed, everyone jumps into action. Meetings get canceled, important details are lost, priorities change quickly, and for a short time, everyone feels busy and important.

This is what firefighting often looks like: a serious bug found too late, a launch delayed at the last minute, or an urgent request that skips all the usual planning. Sometimes, a system only works because a few people know the hidden tricks. These situations bring excitement, stories, and sometimes even rewards. But they also create the false idea that this is how work should be.

Organizations handle firefighting in different ways. Some openly praise it, celebrating those who “save the day,” valuing being available over being sustainable, and mixing up stress with real importance. Others claim to dislike firefighting, but still set up processes that lead to more emergencies. Some teams even believe their problems are special, saying, “This one is different,” again and again.

The real causes of these emergencies are usually clear. They come from delayed decisions, unclear roles, poor teamwork, unspoken assumptions, fragile systems, and rewards for speed instead of careful thinking. Emergencies rarely happen because of one bad day. They build up from many small choices that seemed fine at the time.

Constant firefighting leads to more than just burnout, though burnout comes quickly. First, quality drops because fixes are rushed and don’t last. Then, trust fades as deadlines lose meaning and promises change. Long-term planning is pushed aside because urgent problems always come first. Over time, the organization gets good at reacting but loses the ability to think ahead.

Why is it so hard to set up work to prevent emergencies? One reason is that prevention is invisible — no one notices the problems that never happen. Prevention also means saying no, slowing down, and making clear decisions, which can feel uncomfortable, especially where being busy is seen as progress. Firefighting also gives people a sense of control, even if it doesn’t last.

Looking for root causes isn’t as exciting as fixing emergencies, but it works better. It starts by not rushing ahead. Ask not just what failed, but why it could fail in the first place. Ask which warning signs were missed, which assumptions went unchecked, and which risks were accepted without responsibility. Most importantly, ask if the organization learned anything or just got through another crisis.

Solving root problems needs strategies that may seem dull compared to emergencies. Make sure everyone knows who owns what, so issues don’t get lost between teams. Make work clear enough that problems show up early, not at the last minute. Build systems that fail in obvious and safe ways, not quietly and disastrously. And set up rewards so that preventing problems matters as much as fixing them.

Leaders are important here, but not as heroes. They set the tone by what they reward, allow, and overlook. If people see that escalation works better than planning, they will escalate. If last-minute efforts get praise but quiet prevention is ignored, emergencies will keep happening. Good leadership is less about putting out fires and more about making sure they don’t start again.

Team members also play an active role. Their habits, shortcuts, and silence shape how things work. Speaking up about bigger issues, keeping track of decisions, questioning fake urgency, and making time for real work aren’t rebellious — they’re professional. If a team never pushes back against chaos, it eventually becomes part of the problem.

The hard truth is that many organizations are hooked on firefighting. It feels busy, obvious, and emotionally satisfying. Solving deeper problems feels slow, unclear, and often goes unnoticed. But only real problem-solving can grow with the company. Only it makes room for strategy, quality, and people who want to stay for the long term.

Sometimes, you have to put out fires. But choosing to build a system that doesn’t keep catching fire is up to you.

Every few months, familiar headlines appear again: “The Death of Agile” or “Why Big Tech Is Quietly Killing Scrum.”

The headlines may change, but the message stays the same. Scrum is called outdated, Agile is seen as misunderstood, and somewhere a burn-down chart quietly vanishes from a Jira board.

Is any of this true? In part, yes. But it is not as dramatic as these articles make it sound.

What is really happening is not a revolution, but a slow and awkward step back. The core ideas of Agile — iteration, fast feedback, incremental delivery, and learning by doing — are still strong. What is fading is the version of Scrum that feels like a corporate ritual, with required sprint meetings, an obsession with velocity, endless story point debates, and calendars packed just to look busy.

Large organizations did not suddenly decide to get rid of Scrum. They found that, at scale, Scrum often creates more show than real value. When teams deploy all the time, priorities shift every week, and much of the work is unplanned or comes from interruptions, two-week sprints start to feel like pretending the weather is always the same just because the forecast meeting is on the calendar.

So, Agile is not dead. It has just moved into what you could call its ‘post-framework’ phase.

In this phase, most companies are not swapping Scrum for one new method. Instead, they are building ways of working that match their real needs, not just what coaches recommend. This is when you start to see a range of alternatives appear.

The first and most common change is moving to flow-based delivery, often called Kanban or, more honestly, ‘Scrum without the parts we were pretending about.’ This approach works best when work arrives unpredictably, like in platform teams, infrastructure, editorial tools, internal products, or anything close to operations. In these settings, trying to plan all work into sprints is unrealistic. Flow-based teams focus less on making promises and more on keeping work moving: how long tasks wait, how quickly they progress, and how often they reach users. This suits organizations that prefer steady productivity over dramatic sprint finishes and teams that are tired of explaining why ‘this urgent thing was not planned.’

Another change, especially in product organizations, is splitting discovery and delivery into a continuous dual-track model. This shows up when teams realize their main issue is not how fast they build, but whether they are building the right things. These teams can deliver quickly but often wonder why users do not want what they made. Continuous discovery lets product managers and designers test ideas and prototypes without holding up engineers, while delivery continues as a steady stream of clear work. This model works well for digital products with real users, strong analytics, and leaders who see learning as part of the job, not a distraction.

Another trend is the quiet rise of DevOps metrics as a way to manage teams. In many organizations, story points faded away not because they were wrong, but because they did not mean much outside the team. Executives never really understood velocity, and teams did not think it mattered. Flow and reliability metrics changed this. Measures like deployment frequency, lead time, failure rates, and recovery time are things that engineering, product, and leadership can all agree on. This approach works best for organizations focused on reliability, scale, and operational excellence, such as SaaS, media platforms, and infrastructure-heavy companies. It shifts the question from ‘Did you deliver what you planned?’ to ‘Is the system getting healthier over time?’, which is a tougher and better question.

On another level, there is organizational design, often described through ideas like Team Topologies. This is not just a team method; it is a recognition that no process can fix a poorly designed organization. When teams are overloaded, rely on others, and are unclear about who owns what, more sprint planning will not help. This approach is best for large organizations where coordination is harder than delivering work, and the main problem is mental overload, not individual speed. It is often adopted after years of trying Agile without understanding why things still move slowly.

Finally, there is a model that makes Agile purists uneasy: appetite-based planning, best known as Shape Up. This method works in product companies with strong leadership and stable priorities. Instead of keeping endless backlogs, teams define problems early and commit to a set time frame with flexible scope. It is not more flexible, but it is more decisive. It fits organizations that trust experienced product leaders and want fewer changes in the middle of a cycle. It does not work well where leaders cannot stop interfering with ongoing work, which, to be honest, is common.

Taken together, these models are not a new set of rules. They are a way out.

The main point is not that people are rejecting Agile values, but that they are rejecting fake Agile practices. Teams are tired of acting like uncertainty can be planned out, that velocity means value, and that meetings count as progress. Organizations are moving away from Scrum not because they dislike Agile, but because they are finally taking it seriously.

Scrum is not dead. It is just not the default answer for everything anymore. In a way, that might be the most Agile result of all.

At some point in your career, you realize an uncomfortable truth. Most of your real work happens where you have responsibility, expectations, deadlines, and pressure, but not much formal power.

No one reports to you. You can’t change salaries. You don’t approve promotions. And yet, everyone somehow expects you to make things move.

Welcome to product management. Or leadership. Or adulthood.

For years, many of us try to solve this problem the wrong way. We try to change people, our manager, stakeholders, or even the culture. We think that if we explain better, argue harder, or show one more spreadsheet, things will finally make sense.

They rarely do.

One of the most freeing ideas I’ve learned is simple: you can’t really change your manager. There’s a structural imbalance, and no amount of fairness, logic, or good intentions will fix it. This might sound cynical, but it’s actually freeing. When you stop trying to fix people with more power, you can focus your energy where you do have leverage.

Leverage, as it turns out, looks nothing like authority.

Leverage looks ordinary. It’s built in small moments that go unnoticed — showing up prepared, following through, turning chaos into clarity, and making life easier for others before you need anything from them. This isn’t about playing politics. It’s how trust quietly builds.

Influence grows long before the big meeting. By the time you need it, it’s usually too late to start building it.

Another hard lesson: escalation is not a weapon. If it feels like tattling, you’ve already lost. The best escalations don’t accuse; they invite. They frame a shared problem, show you’ve tried to solve it, and ask leadership to help move things forward, not to pick sides.

This is also where many product people struggle emotionally. We care a lot — sometimes too much. We fall in love with solutions instead of outcomes. We fight for our own ideas when we should focus on solving the problem. Learning to hold onto outcomes and let go of specific paths isn’t weakness. It’s maturity.

Leading without authority also means protecting your team when things go wrong. Don’t blame people in public or say, “Matt misestimated the task.” If something failed, we failed. If something worked, the team did great work. That imbalance isn’t unfair; it’s leadership.

Empathy matters — not the kind you see on LinkedIn with hashtags and stock photos, but the practical kind. Ask people how they want to work. Make space for quieter voices. Admit when you don’t know. Say “I was wrong” without any excuses.

Titles don’t make people follow you. People choose to follow when working with you feels safe, clear, and meaningful.

The irony is that once you accept you have no authority, you often become much more influential. It’s not because you learned a trick, but because you stopped fighting reality and started working with it.

And that, inconveniently, is the part no one can delegate for you.

In 2024, writing about AI became trendy. By the end of the year, it felt like there was too much of it. Every other post, panel discussion, and product update tried to sound smarter by mentioning artificial intelligence somewhere between the start and the end.

Then 2025 arrived, and things changed.

Suddenly, AI was no longer just a topic — it became a required buzzword. Every text included it. Every discussion felt incomplete without a mention. Conference agendas needed ‘AI-powered’ to appear at least twice. Even job descriptions seemed uneasy if AI wasn’t in the headline, ideally in all caps.

Sometimes it seems like we all decided that without AI, our ideas don’t matter, our products are outdated, and our jobs are in danger.

Here’s the uncomfortable truth: life doesn’t stop where AI starts. This is true even if you work in IT, in media, or if your product roadmap has more neural networks than users.

People still disagree — not because there’s not enough data, but because their goals don’t match. Products still fail for human reasons: unclear ownership, rushed choices, fear of conflict, or just not saying “no” soon enough. A bad strategy is still bad, even if it’s dressed up in AI terms and shown with impressive charts.

AI doesn’t replace the basics. You still have to understand your users. You still need to define the problem before you solve it. You still have to explain your choices to people, not to machines. And no amount of automation can fix a team that lacks trust or a plan that changes every two weeks.

There’s also a quiet illusion happening. When everything is called AI-powered, nothing truly is. The word stops meaning technology and starts meaning ambition, worry, or just marketing. We’re not always building intelligence; often, we’re just trying to seem relevant.

Still, expectations keep rising. We want faster delivery, smaller teams, bigger results, and fewer mistakes. AI is supposed to handle the hard work, while people become more strategic, creative, and productive all at once. It’s a nice story, but it’s still just a story.

Looking back on this year, the real challenge wasn’t learning to use AI tools. The real challenge was remembering that AI is just a tool, not a personality. It’s a skill, not an identity. And it’s definitely not a substitute for judgment, experience, or responsibility.

Maybe in 2026 we’ll talk less about AI. Or maybe we’ll talk about it even more. It’s hard to know.

What I do hope is that we will remember how to talk about work, products, and people without sounding like we are trying to impress an algorithm rather than solve a real problem.

People naturally make any space their own. If you give someone an empty apartment, they’ll hang up a plant. In an open-plan office, they’ll claim a corner with a coffee mug that somehow moves from desk to desk. Even in a prison cell, they’ll arrange the bed, tidy the shelf, and talk with their neighbor about invisible boundaries. This isn’t just about decoration—it’s a basic need. Everyone wants a small part of the world that doesn’t require anyone’s approval.

This basic need doesn’t go away at work. It just gets more complicated. Modern offices talk a lot about collaboration, flexibility, and all kinds of desks—shared, hot, warm, but never truly yours. With Slack channels, Teams meetings, and virtual whiteboards, it’s hard to know where your boundaries are. Is this my conversation? Is this my responsibility? Or did someone just hand me a problem because I happened to be online?

Even so, people keep searching for a bit of personal space. They want something that says, “Here, at least, I get to breathe. Here, my thoughts aren’t competing with 47 unread threads.”

Leaders often don’t realize how important this small sense of ownership is. When people feel they don’t control even a small part of their work, they start to pull back—sometimes quietly, sometimes as dramatically as a cat in water. But if you give them space, whether real or symbolic, everything changes. Let someone own a decision, a process, a small project, or just a moment to finish a thought without being interrupted by “quick questions,” and you’ll see productivity become more of a personal mission than a chore.

Creating this feeling isn’t about walls or doors. It’s about signals. In an office, it could be a steady desk or a routine that doesn’t change—a spot where no one moves your keyboard “for efficiency.” On a call, it means giving someone two minutes to speak without jumping in. In Slack or Teams, it’s about respecting boundaries that aren’t written down but still matter: the “off” hours, the “give me context first,” and the “don’t tag me into chaos without warning.”

Even within a project, people need space to feel ownership. They want a part of the work where their input matters, a place where they can make decisions without asking for permission all the time. They want to point to a result and say, “This exists because I shaped it,” instead of, “This exists because the whole team edited the same Google Doc at once.”

The funny thing is, when you give people even a small bit of autonomy, they often contribute more to the whole team. They work together better when they aren’t struggling for space. They communicate more clearly when they don’t have to defend their territory. And they come up with new ideas more easily when they aren’t worried about someone suddenly jumping into their virtual space like a SWAT team.

Everyone needs personal space, especially at work. If you don’t give people a place to stand, they’ll still find one—just not where you expect, and usually not in a way that helps the project.

Give people space, and they’ll deliver results. Take it away, and they’ll take their talent somewhere else that offers more room.

Some teams are predictable: everyone went to the same school, comes from the same country, shares the same jokes, and agrees on what “urgent” means. But most real teams, like the ones many of us lead, are made up of people from different continents, with different academic backgrounds, who speak in different ways and even vote differently. That’s what a normal modern workplace looks like.

This diversity doesn’t stay outside the office — it comes in with us. An engineer with a classical education might see a problem as a Greek tragedy, while one with a background in applied sciences might see it as a math equation. Someone from a high-context culture will look at every detail before speaking, while someone from a low-context culture will get straight to the point in just a few words. An introvert might share their best ideas after some quiet time, while an extrovert may brainstorm out loud, even if no one else is around.

Political views also find their way into the workplace, even if people say they leave them at home. These views affect how directly people speak, how they handle conflict, how they see “ownership,” and how they deal with change. You can ban political debates at work, but you can’t erase the worldviews that shape how people communicate. If only it were that easy.

So, what can a manager do with this lively and sometimes chaotic mix of people?

First, understand that harmony isn’t automatic. The natural state is a bit messy, and your job isn’t to get rid of the noise, but to help shape it. People don’t have to become the same; they just need to learn how to work together without harming the product, each other, or your sanity. This takes some translation — sometimes with language, sometimes with culture, and sometimes with emotions. It might mean explaining that a colleague who “sounded too direct” wasn’t actually upset, or that someone who “didn’t speak up” could still have the best idea.

Second, set up a few shared rules for how the team works together. These aren’t strict rules, but more like helpful guidelines: how to disagree, how to record decisions, how to handle conflicts, and how to ask for help. Everyone keeps their own style, but things run more smoothly.

Finally, there’s a big benefit: if you can keep things on track, this kind of diversity becomes a real strength. Different ways of thinking help teams spot risks sooner, test ideas faster, and avoid making products that only work for people just like you. A team with many backgrounds and personalities can do better than a team where everyone thinks the same, because their blind spots don’t overlap.

In short, the “complexity” that managers sometimes complain about is often their best advantage. The real challenge is to stop seeing it as a problem and start using it as a resource. And maybe, just maybe, to see that the introvert from Moscow, the extrovert from Warsaw, the political moderate from Nebraska, and the philosopher-engineer from anywhere are not a threat to productivity. They’re the reason your team could build something smarter than any one person could alone.

Let’s be honest: most so-called “elevator pitches” aren’t really pitches. They’re just noise, a jumble of loosely connected words, like someone explaining their PhD dissertation to a stranger at a bus stop. And the tragedy is that people do this in front of senior management.

Imagine a situation where an experienced professional tries to describe a solid initiative. It’s a smart, necessary, high-impact effort happening during a private-equity acquisition and a full-scale data-center consolidation. This is the kind of thing that usually makes executives pay close attention.

But the pitch begins with: “Our team is working on many things… this is one of them… it’s quite complex… let me give you the background…”

In an elevator, by the time you’ve said “background,” the person you’re talking to is wondering how long before the doors open and they can escape.

Here’s the uncomfortable truth: Executives don’t want context. They want clarity. They want to hear the pain, the fix, the evidence, the impact, and the ask, all delivered quickly and precisely, like a well-trained surgeon.

An elevator pitch is not a friendly introduction. It’s not a TED talk. It’s not therapy.

It is an IQ test for your idea. If it can’t survive 90 seconds, it won’t survive a budget meeting.

People often think the challenge of an elevator pitch is fitting their story into a smaller space. In reality, the real challenge is removing everything that doesn’t matter. Most pitches fail because they bury the main point in too much detail, too many detours, and too many defensive disclaimers.

The best pitches? They sound almost suspiciously simple.

“Here’s the mission. Here’s the pain. Here’s the fix. Here’s proof. Here’s the impact. Here’s what I need from you.”

Executives appreciate this. It’s not just because they’re impatient, though that’s often true. They want to quickly judge whether you understand your own idea well enough to lead it.

And then there’s the second half of the elevator-pitch problem: Expectation management.

This comes right after the short pitch… and this part is where careers live or die.

When your pitch is vague, people fill in the blanks with their own fantasies: shorter timelines, magical scalability, zero risk, zero cost, instant ROI. And suddenly you’re explaining to a VP why your five-day PoC failed to deliver a full production rollout across three regions.

A good pitch wins attention; a sloppy pitch accidentally promises miracles.

The great pitches must be brutally explicit: “This is what the PoC is. This is what it is not. Here’s the smallest valuable step. Here’s the next decision gate. Here’s what success actually looks like.”

Provocative? Yes. But also responsible. Because nothing destroys trust faster than ambiguous optimism followed by reality. And leaders respect boundaries more than enthusiasm.

A sharp elevator pitch tells them three things at once:

1. You understand the problem.

2. You understand the solution.

3. You understand the risk of overpromising.

That combination is rare. It’s also how trust is built, not with smiles and enthusiasm, but with clarity and clear boundaries.

Let’s be provocative for a moment:

• If you can’t explain your idea in 90 seconds, the idea is not ready.

• If you can explain it but don’t set boundaries, you are not ready.

• And if your pitch creates expectations you can’t control, then congratulations, you have just become the project risk.

The good news? This is fixable.

A strong elevator pitch doesn’t just compress your thinking. It shows whether your thinking is actually clear. And when you finally create a version that’s sharp, crisp, and uncomfortably honest, you’ll notice something new: the elevator doors open, and the person you’re pitching does not walk away. They say: “Let’s talk more.” And that’s when the real work begins.

Delegation can feel odd. Everyone says it matters and wants empowered teams, but many of us still hold onto tasks tightly, afraid to let go. Often, it starts with a simple fear: “What if they mess it up?”

Let them make mistakes, but do it in a smart way. Start by giving responsibility where errors won’t cause much harm, then slowly increase what they handle. Begin with a small task, then a project, and eventually something important. People learn independence much like learning to swim: by getting in the water and practicing, not just reading about it.

Another popular fear: “No one will do it as well as I do.”

You might be great at your job, but your skills alone can’t cover everything. Thinking that only you can do things right isn’t a sign of excellence; it’s a sign of holding on too tightly. The good news is that many people can do just as well as you, and some can even do better. If you step away from a project for a month, you’ll see that things keep moving. Delegation doesn’t make you less important. Refusing to delegate is what puts your role at risk.

Then there’s the manager’s classic: “My team can’t handle these tasks.”

Sometimes that’s true. But more often, it means your instructions aren’t clear, your expectations aren’t stated, and your briefings are confusing. Setting clear goals, writing down the context, giving examples, setting deadlines, and explaining what success looks like all take time. But it takes even more time to redo their work late at night while feeling frustrated.

A more subtle fear: “If I delegate too much, I won’t know what’s going on.”

This is easy to fix: don’t mix up control with watching over every detail. Ask for regular updates that are short and to the point, not long speeches. For big tasks, check in once a week. For fast-moving work, have a quick daily update. This helps you spot problems early without micromanaging.

Another one: “If I give them the task, they’ll think I’m not needed.”

Yes, and that’s the goal. If your team needs you for every small task, it’s not really a team. True leadership is shown by how well your team works when you’re not there to help them.

So, how do you actually delegate without ruining your week?

Start with the “why.” Explain the purpose, the outcome, the users, the constraints. Adults do better work when they know why something matters, not just what needs to be done.

Next, make your expectations clear: explain what success and failure look like, and what decisions they can make on their own. Give examples and compare with past tasks. Clear up any confusion quickly and directly.

Set check-in times in advance. Don’t just say, “Let me know if you need anything,” because that often means people wait too long to ask for help. Decide when and how they should update you, whether it’s a short message, a quick call, or a demo. Having a clear plan helps everyone feel more comfortable.

When the work is done, review it carefully. If it’s good, let them know. People need to hear when they’ve done well. If it’s not good, give honest feedback in a respectful way. Point out what’s missing, what can be improved, and how to do better next time. Feedback should help people adjust, not feel judged.

Here’s another tip: pretend you can’t step in and do the work yourself. If you had no other option, you would delegate well, set clear boundaries, give context, check in as needed, and trust your team. That’s what real leadership looks like.

Delegation isn’t just about letting go. It’s about helping your team take on some of the responsibility.

And yes, eventually your team might handle things even better than you can. That’s not a problem — that’s the goal.