The Young Project Manager

Some Agile teams run all the right ceremonies and still fail to adapt. They show up, they check the boxes, but the outcomes do not change. The problem is rarely the framework itself. It is more often about the kind of effort the team is actually making.

If you look closely, there is a big difference between low effort and high effort actions. Low effort looks safe and smooth but usually goes nowhere. High effort feels uncomfortable, sometimes even disruptive, but it is where real progress happens.

What low effort looks like

Low effort behaviors are easy to maintain because they do not create tension. They follow the script. They look organized. But they rarely challenge assumptions or lead to real accountability.

You have seen this in daily stand-ups when someone says “still working on the same task” and nothing else. Or in retrospectives where people add notes but never follow up. Or in demos that are performed like theater, without changing the product strategy in any way. Even backlog refinement can fall into this trap when weeks go by without anyone asking whether the items are still relevant.

These actions are not useless. They create rhythm. But rhythm without weight is routine. And routines that never break are a form of stagnation.

What high effort looks like

High effort behaviors are different because they demand attention and they change the energy in the room. They are harder, and they often make people uncomfortable in the short term, but they push the team into learning.

Think of a sprint that is re-planned mid-cycle because priorities have actually shifted. Or a user story that is challenged because it lacks value, even if it is already refined. Or a conversation with the product owner where you admit something will not be delivered. Sometimes it even means cancelling a stand-up that no longer helps and replacing it with something that does.

These actions are heavier because they require honesty and courage. They take more emotional and cognitive effort. But they make the team healthier and the product stronger.

Why teams avoid high effort

There is a reason most teams fall into low effort patterns. It is easier.

Confronting blockers means potential conflict. Questioning backlog items means you might upset stakeholders. Changing rituals can feel like a cultural risk. So the team chooses the performance of agility instead of the practice of it. They go through the motions, and because the ceremonies are still happening, everyone feels that work is moving forward.

But the danger is clear: performance without progress. Running a sprint does not mean you are agile. Finishing tasks does not mean you are effective. Without honest reflection and course correction, even the cleanest processes freeze into empty routine. It is like owning a gym membership and proudly saying you work out, without ever really training.

The team might meet, speak, update Jira, and ship features. But no one is stepping back to ask the harder questions: Are we solving the right problem? Are we delivering the right value?

Raising the effort bar

The answer is not to add more rituals. It is to make the existing ones count.

In stand-ups, do not just report. Ask what changed since yesterday and what is slowing us down.

In retrospectives, do not just vent. Ask what we committed to last time and whether we followed through.

In sprint planning, do not just fill the sprint. Ask if these are the most valuable things we could do next.

In reviews, do not just demo. Ask what product or roadmap decisions this demo should influence.

These shifts sound simple, but they are not easy. They require willingness to be wrong, to adapt, to challenge each other in real time. That is the work of an Agile team.

Agile does not need more structure. It needs more intention.

Low effort teams stay busy but stuck. High effort teams often look messy, but they grow because the discomfort forces learning.

So the next time your stand-up feels like a script, or your retro feels like a repeat, pause and ask together: are we actually working, or just performing the work?

That single question might be the point where everything begins to change.

In 2016, I watched a new project manager join a high-profile program. She had an impressive track record, was known for solving complex delivery problems, and came in with energy to match the urgency of the project.

Within her first month, she had already drafted a plan to cut meetings, replace the reporting tools, and “streamline” approvals. On paper, it was solid. In practice, it fell apart.

She had misread the terrain. The weekly meeting she wanted to cancel was the only place two rival directors still spoke directly. The outdated tool she wanted to replace was tied to a compliance clause buried deep in a contract. And the approval process she thought was bureaucratic was actually protecting the project from a political fight she did not yet know existed. None of these things were visible from her first-day perspective.

By month three, her credibility had taken a hit. It was not because she lacked skill. It was because she had moved too fast, making changes before she understood the system she had stepped into. She had treated her first 100 days as a performance review, when in reality, they were a social test.

That is the mistake many project managers make. They rush to “add value” without realizing they are making social withdrawals before they have made any deposits. And in project environments, the social bank account matters more than most people think.

The first 100 days are not for proving you can deliver. They are for learning how the place works. Who talks to whom. Which rules are written and which ones are only spoken about in corridors. How decisions are actually made versus how they are described on the governance chart.

It is tempting to fix inefficiencies right away. After all, project managers are trained to spot waste and improve systems. But what looks like waste may have hidden dependencies, historical scars, or protective functions you do not yet understand. The daily stand-up that feels repetitive might be the team’s only space to surface risks without triggering escalation.

The slow sign-off process might exist because the last time it was removed, the project ended up in legal trouble. In those first weeks, your job is not to redesign. It is to document, ask, and listen.

Tempo matters too. Every organization has its own pace, and every project has its own pulse. Some run like an emergency room, making fast calls with incomplete data. Others operate like a public infrastructure build, where approvals are measured in weeks and documentation is non-negotiable.

You cannot lead effectively until you know which one you are in. The wrong tempo will make you either reckless or irrelevant.

Another early trap is mistaking visibility for influence. Speaking in every meeting, pushing your views before you have context, or trying to dominate discussions will erode trust before it forms. Strategic silence is often underestimated. It gives you time to observe relationships, detect patterns, and learn the real sources of authority. Then, when you do contribute, your words carry weight because they are tied to the group’s actual priorities.

Reputation in those early days is shaped less by achievements and more by behavior.

Do you listen without interrupting?

Do you recognize others’ contributions before adding your own?

Do you ask thoughtful questions instead of rushing to give advice?

These are small indicators, but in a networked environment like project work, they travel fast. They signal whether you are here to build with the team or push your own agenda.

Quick wins can help, but forcing them too soon can create resistance you do not need.

I have seen talented newcomers arrive with dramatic changes, only to watch them collapse because the foundation of trust and understanding was never built.

Sustainable results come from consistent delivery aligned to the organization’s real priorities, not from early fireworks.

I think about it like joining a dinner party where everyone already knows each other. The conversation has its own rhythm, shaped by years of shared history. You do not walk in, rearrange the seating, and take over the conversation. You listen. You learn the dynamics. You understand the inside jokes. Only then can you add something that lands well.

So how do you make those first 100 days count?

Treat them as an intelligence-gathering mission. Map the decision-makers, the informal influencers, and the silent blockers. Learn the history of major projects, especially the ones that failed. Understand how success is defined and who actually gets credit for it. Offer help in ways that fit the current flow rather than disrupting it. Keep your promises small but consistent. And when you speak, make it clear you are building on what you have learned, not replacing it with something imported from elsewhere.

Your first 100 days are the foundation of your influence.

They are not about delivering the biggest milestone, but about earning enough trust to navigate the complexity that comes later. Projects run inside webs of relationships, politics, and unwritten rules. If you understand that web, you can deliver without constant friction. If you ignore it, you will spend months fighting battles you never needed to fight.

Performance will always matter, but in a new environment, trust is the first deliverable. Build it deliberately. Everything else will be easier after that.

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.