The Young Project Manager

There is something deeply human about sticking with a decision that no longer makes sense. We see it in everyday life. You buy groceries you never eat. You keep a subscription you forgot to cancel. You sign up for a gym in January, go twice, and still pay for it all year. But you don’t cancel. Why? Because canceling feels like giving up.

That’s exactly what economists Stefano DellaVigna and Ulrike Malmendier studied. In their research "Paying Not to Go to the Gym," they tracked people who chose expensive monthly gym plans, thinking they’d go often. Most ended up going just a few times but kept paying for months. People prefer to keep spending than to face the emotional cost of admitting they were wrong.

Now think about your team at work.

How many projects are still running, even when it’s clear they won’t deliver value? How many backlogs are full of ideas that no one really believes in anymore? And how often do you keep pushing through, simply because stopping feels worse than continuing?

This is not just about money. It’s about psychology. And teams fall into this trap all the time.

There are a few reasons why this happens:

1. The fear of looking inconsistent

People want to be seen as reliable, committed, and confident. Saying “we were wrong” or “this is not working” feels like failure, even when it’s actually a smart move. Leaders especially fear the judgment that comes with changing direction. But consistency isn’t the same as wisdom. Sticking to a bad plan is not leadership. It’s just inertia.

2. The sunk cost fallacy

The more time, money, or energy you invest in something, the harder it is to walk away. This is a powerful bias. We say, "We already spent months on this," or "We can't stop now, we are too far in." But that’s backward logic. The cost is already gone. What matters now is whether continuing will create value in the future.

3. Lack of psychological safety

In some teams, people don’t feel safe to speak up. If someone says, "This project isn’t worth it anymore," they fear being seen as negative, lazy, or disloyal. So everyone stays quiet, even when the problem is obvious. A healthy team needs space for honest conversations, even if they are uncomfortable.

4. Overconfidence in the original plan

Many teams mistake initial enthusiasm for guaranteed success. Plans made in slide decks six months ago are treated like promises carved in stone. But markets shift, users respond differently, and unknowns appear. Flexibility is not a weakness. It’s a sign of maturity.

5. Too much pride in effort

There is emotional weight in work already done. You feel attached to what you built. You remember the long nights, the heated meetings, the compromises. Killing the project feels like throwing all that away. But effort without outcome is not progress.

Now, let’s flip the perspective.

The best teams are not the ones that finish everything they start. They are the ones that know what to stop.

They build pause points into the process. They ask early: Are we still solving the right problem? They revisit assumptions. They measure reality, not just intention. They know that changing course is not the same as failure. It’s adaptation.

In Agile frameworks, this should be natural. We talk about iteration, learning, responding to change. But too often, Agile becomes just rituals. Sprints keep happening. Backlogs keep growing. Velocity gets tracked. And nobody asks the real question: Should this exist at all?

Here’s something simple your team can do:

At the end of every sprint or quarter, ask: If we had to decide today, would we start this again from scratch?

If the answer is no, it’s time to stop. Or at least to rethink.

Leaders have a responsibility to model this thinking. To show that changing your mind is not a sign of weakness, but of awareness. To create space where teams can be honest about what’s working and what isn’t.

The gym contract study wasn’t just about fitness. It was about identity, pride, and loss aversion. And that plays out in every workplace too. The longer you hold on, the harder it is to let go. But letting go is often the smartest move you can make.

Smart teams don't just deliver. They decide. And deciding what not to do is half the work of good leadership.

Canceling is not quitting. It’s choosing again, with better information.

That’s strategy. That’s clarity. That’s progress.

Why Process Alone Rarely Works

Let's be very honest from the start. As project managers, we often feel comfortable with processes. We like frameworks because they offer something clear to hold onto when uncertainty hits the project. Maybe it’s a survival mechanism, something we use to feel more in control.

I've been there myself, especially in my early years managing IT projects in small Brazilian companies, where chaos felt like a daily visitor.

Agile is particularly appealing because, at least on paper, it offers simplicity: quick feedback, regular check-ins, small teams, and constant improvement.

But anyone who's led Agile teams in practice (not just read about it or heard it from consultants) knows things rarely turn out that way. If Agile really worked as smoothly as promised, we wouldn't be having this conversation.

After managing dozens of Agile projects, from healthcare software to complex digital transformations, I noticed a recurring problem that no Agile guide or Scrum manual openly addresses.

They all quietly assume teams have trust, but almost none actually do. And that's why, despite following the process exactly, Agile often fails quietly.

Trust: The Invisible Metric

Trust isn't just a nice idea. It's the hidden driver behind every good decision, every meaningful meeting, and every honest retrospective.

Without trust, meetings become just meetings. People smile, say what they're supposed to say, and quietly move on. They don't speak honestly about what's wrong because they've learned (through painful experience) that honesty doesn't always get rewarded.

I saw this clearly while leading a high-stakes project for a global automotive client here in Sweden. The Agile metrics looked perfect: velocity stable, burndown charts neat, tickets moved smoothly. But if you sat in the meetings, you'd see polite nodding, safe answers, and cautious smiles. Real issues (like unrealistic deadlines or major technical risks) stayed hidden. They were discussed quietly in side conversations after meetings, not openly in the team. People weren't lazy or dishonest, they were simply smart enough to avoid conflict that didn't lead anywhere.

Trust isn't measured on a dashboard, but you immediately notice when it's missing. You see it in how honest the retrospectives are. You feel it when teams stop pushing each other. You hear it in the polite silence when difficult questions arise.

How Agile Quietly Breaks

When trust disappears, Agile doesn't collapse loudly, it just fades quietly into empty rituals.

Daily standups become status reports, retrospectives turn into gentle sessions about minor issues ("we need better tickets" or "fewer meetings"), and planning becomes just a formality.

This reminds me of football matches (soccer, for my friends in the US) I watched growing up in Brazil.

When players feared losing their spot on the team because of one bad pass, the game was painfully cautious. Nobody took risks, nobody created opportunities. They just played safe passes, avoiding mistakes.

Agile teams without trust look exactly like this. They’re safe but boring, structured but unproductive.

How to Recognize Trust Problems Early

So, how do you notice trust is fading early enough to act on it? Here are some signs I've learned to spot clearly over the years:

• Meetings become quieter. People speak less honestly.

• Retrospectives become predictable and safe. No one mentions uncomfortable truths.

• Risks and issues emerge suddenly, without warning. People saw them earlier but kept quiet.

• Side conversations after meetings happen regularly, showing important conversations don’t happen openly.

Practical Ways to Rebuild Trust in Agile Teams

Here's the reality: rebuilding trust isn't easy. It's slow and careful work, done daily. It doesn't happen through a speech, an email, or a single retrospective. It requires consistent small acts that build a culture of openness.

Based on my experience (and mistakes), here are concrete actions you can try:

• Openly admit your own mistakes first. Leaders set the tone. If you admit your mistakes openly, others will feel safer doing the same.

• Show that feedback leads to action. Even a small action matters. If someone gives feedback during a retrospective, act visibly on it. It shows you’re serious.

• Ask uncomfortable questions openly. Don't pretend things are fine if they're not. Directly ask your team, "What risk are we ignoring?" or "What issue do we pretend doesn’t exist?"

• Protect people who speak openly. If someone risks being honest, publicly thank them, support them, and make sure they're not punished for their honesty.

I remember a specific project when I openly admitted to the team I had misunderstood our technical limitations. It wasn't easy to admit. But after I did, something changed.

People started speaking up more openly about their own uncertainties and problems. It was like opening a valve, tension disappeared, and we actually solved real issues quickly.

Stop Confusing Compliance With Trust

Here's an uncomfortable truth many leaders ignore: compliance (people following the process) isn't the same as trust.

You can have a perfect Agile team in theory (standups, retros, velocity charts) but zero trust. I’ve seen this clearly, especially in corporate environments where people learn quickly to appear compliant to survive.

But compliance doesn't create innovation, honesty does.

Trust is like a battery. It charges slowly but drains quickly. Every meeting, every conversation, either charges or drains it. Protecting that battery isn't a side task, it's your core responsibility as a project leader.

The Real Work of Agile Project Management

The real work in Agile isn't about processes, tools, or frameworks. It's about creating conditions where people feel safe to speak honestly, openly, and sometimes uncomfortably. It's about building trust.

Everything else—tools, metrics, rituals—is secondary. If trust is high, even imperfect processes deliver excellent results. If trust is low, the best Agile processes in the world won't help.

So before your next retrospective or planning session, think deeply about these questions:

• Can people safely disagree with the plan?

• Will honesty be rewarded or quietly punished?

• Is your team truly open, or is it just politely compliant?

These questions aren't theoretical. They're deeply practical and necessary. I've learned, through successes and hard mistakes, that if you get this right, the rest comes easier. Projects move faster, people are happier, and results become visible.

Trust Is the Metric That Matters Most

As project managers, our job isn't just managing processes. We manage human conditions.

We create (or fail to create) an environment where honesty and courage become normal behaviors. Trust is the most important condition. It's the metric we rarely track but always feel.

If you care about your team's success, don't spend your next week optimizing processes. Spend it optimizing trust. Because Agile without trust isn't Agile at all. It's just another way to organize silence.

This isn't just theory or nice advice. I've seen it in practice. I've watched teams unlock their best work or quietly fail, and the difference was always trust. It's that simple, and that complicated.

So, my invitation to you as a fellow project leader is this: Don't settle for rituals.

Focus instead on creating a space where difficult truths can be said out loud. Build trust intentionally. It won't happen overnight, but it changes everything once it does.

Let's build Agile teams worth leading. Let's measure success not by process adherence, but by trust and honesty. That’s the only metric that truly matters.

There is a scene I know too well. You finish a stakeholder meeting. Everyone nods, says “makes sense” or “let’s move forward.” The project seems aligned.

Then nothing happens.

Approvals stall. Decisions get delayed. A few weeks later, someone who agreed in the meeting quietly resists the plan. You end up chasing outcomes that should already be done.

You review your notes. The meeting was fine. Emails were clear. Roles were defined. So what went wrong?

Here is the real problem...

People rarely say what they truly think in group settings. Especially when their concerns might slow things down, challenge a senior sponsor, or make them look difficult. Instead of pushing back, they stay quiet. They wait. That silence becomes the very thing that derails the plan.

This is not bad behavior. It is basic psychology.

In workplaces where speed is rewarded, where teams are understaffed, and no one wants to be labeled a blocker, doubts get hidden behind polite agreement. I have done it myself probably.

It is easier to nod and say “sounds good” than to ask an awkward question in a room that clearly wants to move on.

That is how projects run into invisible walls. You think you have alignment. What you really have is a thin layer of consensus covering unspoken fear.

Fear of being blamed. Fear of wasting time. Fear of getting pulled into something with no clear exit.

This fear does not show up on the project plan, but it is embedded in the system.

What we often call “stakeholder resistance” is usually just discomfort that never had space to surface. You did not fail to communicate. You missed a conversation that never happened, because the other person did not believe you truly wanted to hear what they had to say.

So what actually works?

Not another alignment session. Not more slides or documentation.

It comes back to something basic but often ignored: relationships.

You have to earn the version of the truth people will not share in a meeting. And that requires more than asking for generic feedback. It demands patience, genuine curiosity, and one-on-one conversations.

Sometimes it is as simple as saying, “I have been thinking about this project. Is there anything bothering you that we have not talked about?”

You are not looking for drama. You are looking for reality.

Yes, this feels slow. But it is far slower to redo work later because no one voiced a concern earlier. The hidden cost of avoided conversations is high. We pay for it in rework, friction, and teams that slowly disengage.

One thing I do on every new project is write down a question I want to keep in front of me throughout:

Who is staying quiet because they think it is not worth the risk to speak up?

If you can answer that early, you will avoid the illusion of alignment and last-minute surprises. More importantly, you will build something that no roadmap captures: trust that does not need a meeting invite to show up.

So next time everyone nods and says they are on board, ask yourself what they are not saying out loud.

Because if you want a project that actually moves forward, you cannot just manage the work. You have to learn to hear the part of the room that never speaks.

Agile began with something very simple. People wanted to build software in a smarter way.

Developers were tired of writing endless documents, getting feedback too late, and delivering things customers did not want. So they wrote a short manifesto. Four values. Twelve principles. No rulebook. Just guidance on learning, teamwork, and improving how they built things.

At first, it worked. Teams spoke more. They delivered in small pieces. They adapted fast when things changed. Feedback was early. They felt ownership. Customers got something closer to what they needed.

Then popularity arrived.

Big companies wanted Agile because they heard it was fast and cheap. Consultants sold it. Certifications appeared. Scrum. SAFe. Kanban. Agile became a product to buy.

We turned Agile into a process, not a mindset.

Teams now follow rules instead of thinking. They run ceremonies, fill in Jira, write user stories, count story points. The learning often disappears. The link between the team and the user weakens.

Look at standups. Once they were quick, useful check-ins. Now they are scripted. People repeat what they did, what they will do, what blocks them. No one really listens. Managers treat them as status updates. Teams just want them over. That is not collaboration. That is theater.

Retrospectives have the same problem. We discuss what went wrong and how to improve. But the same issues return. Why? Because they live in the company culture. No process fixes culture if no one really wants change.

Agile did not fail. We used it to look busy without truly changing.

Agile was supposed to help us learn, not measure factory output. But companies use velocity and story points to judge teams. That turns learning tools into targets. Teams inflate estimates. Split work oddly. Rush tasks. The metrics look good. The software does not.

Even worse, we abuse the phrase “working software.” If it runs, we ship it. Even if it is a mess. Slow. Hard to test. Painful to change. Good software is not just code that runs. It is code that is simple, clear, and easy to maintain.

Agile was supposed to help us build that.

Planning also went wrong.

Agile was meant to replace big, fixed plans with short, flexible ones that adapt as we learn. But most companies want control. They want to know exactly what happens next quarter, even if it is guesswork. So we fill backlogs with fake certainty. We pretend we can predict the future. When reality changes, we blame the team.

That is not Agile. That is old thinking wearing a new shirt.

And we forgot the user.

Many teams just deliver features from a list. One after another. No one asks, “Is this the right problem to solve?”

Agile was not about speed. It was about learning.

Speed happens when learning is strong. If you only chase speed, you lose quality. When quality drops, everything slows down.

So what can you do?

Start small. Be honest. If your meetings are useless, stop them. If your metrics do not teach you anything, drop them.

Ask your team: What works? What wastes time? What is unclear?

Talk to users. Share what you build early. Ask questions. Change what is not helping.

Remember why Agile started.

It was not about sprints or story points. It was about working smarter. Listening. Building carefully. Staying flexible. Learning quickly.

You do not need a new framework. You do not need a big transformation plan.

You just need to take the original values seriously.

People over process.

Working software over documentation.

Collaboration over contracts.

Responding to change over following a plan.

It is hard. But it is better than pretending.

Most postmortems on AI projects are too nice. They use vague terms like “stakeholder misalignment,” “technical complexity,” or “change resistance.” But those phrases are polite masks. The deeper truth is this: AI projects don’t fail because AI is too advanced or complicated.

They fail because organizations are not ready to face their own behaviors, habits, and assumptions.

Let’s stop tiptoeing around the real issues. If you want your AI initiative to deliver more than a slide deck and a few experimental demos, you need to look beyond the surface. The failure patterns are not always technical. They are systemic. And very often, they are human.

They don’t happen because people are bad at their jobs. They happen because we underestimate how AI challenges our existing systems of work, power, and trust.

Let’s walk through the real reasons AI projects stall, break, or quietly disappear.

1. The Budget Was Approved, But the Commitment Wasn’t

A common trap is treating AI like any other tech investment. The budget gets signed off. A product owner is assigned. Maybe there’s a flashy kickoff. But no one has asked the harder questions:

• What will success actually look like?

• How long are we willing to iterate before seeing value?

• Who defines what "done" means?

Instead of a clear outcome, teams chase vague goals. Reports are filled with optimistic language. Everyone assumes someone else is keeping track. Six months later, an executive casually asks, “So… what have we achieved?” And the room gets quiet.

This isn't about money. It’s about clarity. If you don’t define success up front, you’ll end up building something you can’t measure—and can’t defend.

2. Real Requirements Got Lost in Translation

From vision to delivery, AI projects involve layers of interpretation. Executives describe a goal. Product owners shape that into initiatives. Data teams model the problem. Developers ship code. But somewhere along that path, the signal starts to fade.

Sometimes the input data is flawed. Sometimes the problem being solved is no longer relevant. Sometimes the algorithm is solid, but the end-user doesn’t trust the result.

The result? A recommendation engine nobody believes. A prediction model that nobody acts on. A dashboard that looks sleek but sits untouched.

AI is about solving a problem that matters to someone. And that person needs to see the connection between your model and their real-world pain.

If the outcome doesn’t change behavior, it doesn’t matter.

3. The Organization Isn’t Culturally Ready for Feedback Loops

AI lives on iteration. It depends on feedback, learning, and the ability to say, “this didn’t work, let’s try again.” But many companies are still operating in environments that punish failure and demand certainty.

In those cultures, teams hesitate to release anything that isn’t perfect. Leaders ask for guarantees. Project reviews turn into blame-avoidance rituals. Governance becomes a bottleneck instead of an enabler.

People wait for direction. And when it finally launches, it’s outdated or too safe to matter.

Building successful AI requires cultural maturity. It needs an environment where people are rewarded for learning fast—not just for avoiding mistakes.

4. The Org Chart Still Controls the Decisions

This is one of the quietest but most dangerous failure patterns.

AI systems are supposed to speed up decision-making and reduce the need for manual judgment in repetitive scenarios. But many times, the project stalls because someone with political power feels threatened. Not directly. Not openly. They’ll say things like “the model isn’t ready” or “this isn’t the right moment.”

But beneath the words is fear.

Fear of being bypassed. Fear of being questioned. Fear of an algorithm making recommendations that don’t follow traditional hierarchies.

When that fear isn’t addressed, it wins. The project gets blocked, delayed, or deprioritized. Not because it doesn’t work—but because it works in ways that challenge how decisions have always been made.

5. Complexity Without Usefulness

AI teams are often made of brilliant people. Engineers, scientists, researchers—people who love the elegance of a powerful model.

But that love can lead to overengineering. Months are spent on improving accuracy by another percentage point. Technical debt grows. But no one checks if the final result fits into the actual workflow.

And here’s the catch: the end-user may not care about 94 percent accuracy if they can’t understand why the system made a recommendation.

The most useful AI tools are often the simplest ones. They don’t just predict well. They explain. They integrate. They help a real person take action with more confidence.

Without usability, even the most accurate model becomes a fancy report generator. A great AI project is one that people use, trust, and rely on—not just admire in a demo.

6. Misaligned Incentives Across Teams

In theory, everyone supports innovation. In practice, everyone protects their territory.

In an AI project, data teams want to protect data quality. Legal wants to avoid risk. Sales wants faster delivery. Compliance wants control. And the product team wants to move fast and test ideas.

When those goals clash, and they always do, the AI initiative becomes a negotiation arena. Meetings slow down. Trade-offs are delayed. People nod in public and resist in private.

You can’t align incentives perfectly. But you must surface them early. Successful AI efforts are backed by leaders who are willing to challenge silos and say, “this is the outcome we care about, and we’ll measure all teams against it.”

Without that alignment, progress will be slow, painful, and often invisible.

7. Metrics That Look Good But Mean Nothing

A common post-launch headline: “Model performance exceeds 90% accuracy.”

Great. But what changed?

Did the model help people make better decisions? Did it save time? Improve safety? Increase revenue? Or was it just another box on a dashboard that no one really checks?

Real success in AI is not measured by model performance. It’s measured by behavioral change.

If users are ignoring your AI, then your project didn’t succeed. Even if the math is perfect. Even if the code is elegant. Even if the charts are pretty.

True AI value is when people trust the system enough to act on it.

So, What Does a Successful AI Project Actually Need?

This is the part where most people want a checklist. But what AI success really requires is systemic readiness. Not just tools and talent, but organizational honesty.

You need:

• A shared, specific reason for doing the work.

• Decision-makers who stay engaged and face trade-offs.

• Teams who feel safe being wrong and learning in public.

• Feedback loops that are welcomed, not punished.

• Metrics that show adoption and impact, not just performance.

And above all, you need to stop thinking of AI as a technology project. It’s a mirror.

It reflects your organization’s values, priorities, trust dynamics, and cultural posture toward change.

If your AI project is struggling, it’s not just about the model. It’s showing you how your system behaves under uncertainty. That’s the real data. And that’s where the transformation begins.