Don't Fix Anything

Picture this. 

You come into a new job. You’re the star hire. You’re in meetings, you’re listening to how the teams function, and you just KNOW you’ve found the problem. It’s so obvious - clearly, they just needed someone to come in fresh and see that the Emperor Has No Clothes. 

You write up a plan: “Here’s what’s wrong, and here’s how we fix it.” You bring it to the next team meeting, two weeks into your hire, to tell everyone what’s going to change. Your proposal is brilliant and simple. You have flowcharts and graphs to help people follow along. 

The room goes silent. It’s that awkward kind of silence that makes you think you just said something incredibly stupid. Someone asks a question in that gentle voice that suggests they’re trying to lead a child to the right answer. No one else engages or debates.

What the hell just happened?

You know how to onboard! You met the stakeholders and established personal connections; you observed the meetings and understand the team’s functions; you reviewed their tools and shared understanding.  You are a professional; you’ve done this before, and your plan is built out of fresh observation. 

How could fixing the problem be the wrong thing to do? Aren’t quick wins supposed to be your focus in the first 90 days (thanks, Michael Watkins)?

Don’t do it. Pitfalls are lurking around you in those 30 days that you must avoid at all costs. 

The Honeymoon Period

The “honeymoon period” is a sword that cuts both ways.  They don’t know any of your past fuckups, and as far as they know, you are the version of you that you shared in your interviews. But they also don’t know if they can trust you. Or, in some cases, if they can make use of you.

You are going to get a mix of the brutal truth they can’t tell others (because you don’t have a dog in the fight yet) and the surface politeness and chicanery they think they can get away with.  

Examples: 

• Let’s say a stakeholder has been stonewalled by your BU because their requests are bullshit. That person, when you show up excited to be effective and helpful, will peg you as a way to bypass that stonewall. And if you listen to them, you’re going to lose rapport with your team because you just made their jobs harder. 

• Let’s say you’re getting the brutal truth out of one team member about the team’s dysfunction. This is valuable data!  AT THE SAME TIME, you’re getting it without history, context, or the “metadata” that tells you if this reporter has just had a shitty quarter and is overly indexed on recent events. You could be spending time solving a problem that doesn’t really exist. 

The point is, you’re not in a position to have a fully calibrated “spidey sense” for this new environment yet. Even if your years of experience are telling you what you need to do? Proceed with heavy fucking caution. 

So, what do you do instead? 

At first, just gather information. You know the questions to ask: what’s your biggest challenge? where do you see an opportunity for the team to get better? who should I be talking to?

Track all of it. Build up a learning and relationship backlog. Identify your unknown unknowns. Get that shit sorted before you start making waves.  

That Broken Process Is Someone's Life Raft

No matter how broken a process is, somebody put it there. 

If it grew organically over the last several years and is outdated and slow, but no one has fixed it, I can guarantee you it’s hiding people’s ability to slack off or make the easy, less productive decisions. These people will usually fight to keep the bad process.  But there’s a flip side here: if people are fighting for slack or sloppy work, does that mean someone needs firing? Or is there something else going on, like ridiculous demands or understaffing? And if you’re going to advocate that someone needs firing.? Take the time to make sure you’re right, and buckle in for a long termination process. 

If there’s a process in place that should be streamlined and effective but which nobody follows, then there is an inherent flaw that process doesn’t account for. If you want it to work, you need to figure out what need that perfect process isn’t meeting and fix that. In these cases, it’s common to hear “I don’t know how to fix it” when you ask people. You’re going to have to do some sleuthing. And that takes time.

So what do you do?

Everything you’re seeing is data, and honestly, it serves as a foil for what the one-on-one stuff tells you in the honeymoon period.  If you’re hearing that everything’s fine but the process is crap, you need to learn where the issue really lies. 

I recommend tracking what you see, who engages with it, who loves it or hates it, what problem it’s meant to solve and what it actually ends up doing. Write it up; don’t just keep it in your head. You need to see in black and white what the reality and the illusion are.  

You're Spending Trust You Haven't Earned

If you are going to make big changes or even small changes that affect people’s day-to-day, over and over, you need buy-in. As PMs, we all know this. Buy-in and how to get it are in just about every book and blog. But what do we mean?

• Let’s say the status reporting on your program has been a mess for years. The red/ yellow/green have been delayed versus project reality, and every other week, the team is in an overnight fire drill to get the project tickets in a state to justify whatever green means this week. You fix it.  Status colors are based on a clear set of rules that are also communicated in the report. You boldly mark the latest report as yellow because the schedule is at risk and you need executive help removing a blocker. Leadership removes the blocker, but they’re now paying attention, and they want to know why the tech team isn’t delivering on a frequent basis. Next thing you know, you aren’t in the monthly business reviews anymore. You’ve been dropped from the invite list. And a colleague generously offers to take over the reporting. What you missed? That confusing color issue was by design, not by accident. Someone in your BU wants to manage up by keeping leadership out of the day-to-day, and green statuses let them do that. You were right, but you were also a problem someone decided to solve. 

People nodding their heads is not enough. You need people to execute those changes while you’re not around to look. Otherwise, you’re going to end up as a 14-hour-a-day, burnt-out PM, and nothing will improve.

How do you get people to do what you want? They need to trust and believe that what you’re suggesting will actually work. They need to see competence in your day-to-day, talking in meetings, removing obstacles, and solving problems. They need to find you comfortable to work with.  If you can build that up, then they’re more likely to make the investment in the effort it takes to change muscle memory. 

And that takes time.

So what do you do?

Relationship-building and a stakeholder register/engagement tracker are mandatory. Again, since you don’t have spidey sense yet, you need data. You need to see patterns. And you need to be able to predict how people will move.

Always remember: don’t hang your ass out to dry without a very good reason. Competence without political cover is exposure.

You Don't Have Time to Both Diagnose and Roll Out

Thirty days is about two two-week sprints. That’s enough to form an opinion, maybe enough to design a fix. What it doesn’t give you is time to roll out change management.  

What do I mean?

• First, you need to gather the authority/agreement that will let you make the change. Those ‘dotted-line’ authority issues will get you, especially if you run up against one of those people benefiting from the status quo.  The reverse is also common - people can be so engaged and earnest that they actually care that someone is trying to improve the workflow. This is great!  But it also leads to multiple people having strong opinions they aren’t prepared to let go of (i.e. repeated decisions or ‘swirl’.)

• Second, you need time to explain it to people. We would all like to believe that can explain something once to adult, competent colleagues, but that’s not the case. In these understaffed, fast-paced teams, the extra thought it takes to do something different from what they’ve done before is tricky. They’ll hear your pitch, decide if it impacts them negatively, and let it slip out the other side if they think other things require their attention more. 

• You’re going to have to tell them more than once. You should consider explaining it like they’re five (they’re not dumb; they don’t have time or attention to absorb what you’re asking). And you are going to have to document it, draw it, and maybe even take it on a road show - spreading the gospel of the new process to different teams/people. 

All of this takes time.

So what do you do?

I bet you can guess by now. 

• Document your plans. 

• Give folks a date for a date if they need proof of forward progress. 

• If you can identify a simple, safe quick win, then do it - but choose something with small effort, higher reward. Can something be automated? Given to AI? Can you stop doing something (my favorite).

  
  

The Personal Risk Register 

You can pull all of this record keeping/data gathering into a personal risk register and track all four categories of risk. 

Treat all this onboarding info as hypotheses. They could be true, they could be partially true, or they could be dead wrong. Track it all - the learning and relationship backlog, the bad process observations, and the ins and outs of getting team members to “I can live with this” in this risk register.  Then over those 30 days, see what pans out, what’s false, and where the pitfalls yawn widest. 

Here's what that actually looks like. Remember that stakeholder from earlier, the one who wants you to fast-track something your team's been sitting on? That's not a favor to decide on the spot. That's a register entry.

• What happened: Stakeholder asked me to unblock a request my team has apparently been slow to deliver

• Source: One person, one conversation, zero corroboration.

• Hypothesis: Could be my team dragging their feet, could be something that fell through the cracks, could be a communication error. Could be a legit ask inside a crazy one.

• Risk if I act on it wrong: I fast-track it, it turns out to be the bullshit version, and I've spent trust with my own team in week two while making myself the new back door everyone routes around old decisions through.Status: Validated

• Final decision: Stakeholder is usually asking for unreasonable things, but we did actually drop this legitimate ask. 

• Stakeholder note: Stakeholder is one to keep an eye on; not everything that comes in needs direct action.

From there, you’ll have a solid basis for your spidey sense. Use it to figure out what you really need to do for your 60- and 90-day tasks to create not just a solution, but to create a solution for that solution - how you’re going to get it done with THIS TEAM.