The Young Project Manager

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.

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.