Learn the Game, Play the Game

You can't be an effective project manager if you don't understand how your organization makes decisions. If it feels like the powers at be are blocking your project, you probably don't understand it from their perspective.

I've been chatting with a lot of Scrum Masters, Product Owners, and Developers at trainings the past few months and a common theme that keeps popping up is "We could get so much more done if our client/executive/boss would get out of the way. They don't trust us and their approval holds everything up."

"We could get so much more done if our client/executive/boss would get out of the way. They don't trust us and their approval holds everything up."

When we dive deeper, the root cause is always the same: the development team is optimizing for an idealized approval process with different values than the approver.

We're taught to believe that organizations are black and white, that people make rational decisions, and businesses always put customers first. It's completely wrong. No matter who you are in an organization, it's your job to understand the game and optimize for how it's played.

You can't win the game if you don't know the rules. Source: Pexels

The last time I worked with a federal client, I was a Scrum Master and Product Owner for a federal agency's cybersecurity projects. I can't go into the details of what we were working on, but the gist was to make routine cybersecurity tasks more efficient. I started as the new Product Owner for a project already 18 months behind schedule.

I was not and am not a cybersecurity expert, but I have a lot of experience managing risk and evaluating decision making processes. The frameworks of risk management are similar across all fields, it's just the details and sources of risk that are different. So when the team told me the delays were due to disengaged decision makers, I noted their concerns, but also kept an eye on how the approvers behaved.

I quickly realized that the team and prior Product Owner had not taken the time to view the project from the perspective of our approvers. For example, the system I inherited was already more secure and easier to use than the status quo, but did not meet current best practices for cybersecurity. If we implemented it, the organization would be more secure, but would not be in compliance. The question was if we should implement it today. An economist, and the team, would tell us the answer is obvious: you're better off with the new system than the old one, even if it's non-compliant.

Here's what actually happened:

Client: "It's not secure according to our standards."

Me: "Correct, but neither is the status quo and it is far more secure than what we use now."

Client: "But it's not up to our standards."

Me: "Do you agree that it's more secure than what we have?"

Client: "Absolutely."

Me: "So we should use it?"

Client: "Absolutely not. The prior system is already authorized. I won't authorize something that's insecure."

Bingo! It was never just about security, it was about accountability. The prior system was authorized by prior leadership, meaning that issues with the system could be attributed to failings in THEIR judgement. For the current leadership to change the status quo, they had a much higher bar for security, customer satisfaction, and other requirements because THEY would be held accountable. Just because the prior administration approved something worse, doesn't mean current leadership would accept an insecure system.

So what did I do? I studied, asked for help and guidance from our cyber experts, went through every cybersecurity standard and regulation, and reprioritized the product backlog and testing to reflect the true decision making process. The features that were most user-centric were no longer the most important, because they would never be launched until we met minimum security thresholds, even if our system's security already exceeded the status quo. Once we focused on getting approved over being idealistic, we sped up the launch time immensely and saved the project. We had then earned the the right to delight users.

Is it how agile is supposed to work? No. Is it what we needed to do to succeed? Yes.

Optimize for how the organization works, not how it's supposed to work. Source: Pexels.

Approval barriers weren't limited to the client, they also popped up when working with our subject matter experts and solutions architects. For example:

Solutions Architect: "You need to tell your developers they're doing it wrong."

Me: "Hmm?"

Solutions Architect: "The feature they're building is suboptimal."

Me: "Why?"

Solutions Architect: "It doesn't follow best practice."

Me: "Does it achieve the same outcome?"

Solutions Architect: "Yes."

Me: "Does it create some other issue or risk that I'm not seeing?"

Solutions Architect: "Yes. It's not best practice."

Me: "Why is that important? What's the issue?"

Solutions Architect: "It's not best practice, and I won't support or authorize shoddy work."

Boom! We couldn't get work in front of the client because our internal experts blocked it to protect their brands and expertise. So what did I do? I built check-in and discussion points with Solutions Architects earlier in our requirements gathering and development processes. Little about the solution changed, but they felt included, heard, and more comfortable with the decisions the development team made.

Should folks outside the development team determine how work is completed? No. Did it "slow" the development process? On paper, yes. In reality, no. We were much faster because we sped up the approval process through the buy-in and support of our experts. We created a system that was trusted and supported, even if it wasn't the "right" way to develop.

The funny thing is that by sacrificing my preferences and ideals for project management to optimize for others, I was able to earn them back and then some through successful product launches. The client and our management became interested in what I was doing because my projects shipped. When I provided recommendations for what we could do better, they listened because of the trust and goodwill I had built by prioritizing their time, effort, and decision making over my own. By the time I left, our development process was transitioning towards agile best practices that had seemed impossible to implement only a few months earlier.

The client and our management became interested in what I was doing because my projects shipped.

So what did I learn from this project?

1. Projects exist within the organization's decision making framework, not separate from it. In my eyes, the cardinal sin of a Project Manager/Product Owner is willfully pretending their project exists in a vacuum. You are doing a disservice to your organization, your team, and yourself if you do not observe and study how your organization makes decisions and your project's place in the organization's strategy. You must manage the situation you are in, not the situation you want.
2. Optimize for how decisions are made. Cardinal sin number two is willfully pretending that organizations are rational monolithic actors built to please customers. They are not. If your boss/client is meddling in the project in an attempt to get promoted, find out how they get promoted. Build products that delight customers in a way that gets them promoted. Management is much easier when individual success is aligned to project success.
3. Build around your team's personal preferences, habits, and quirks. I worked with a cast of characters. All were brilliant and talented, but some couldn't be in the same room together. Is that a healthy environment? No. Is that the environment we had? Yes. It's easy to throw your hands up and say it's too difficult or people are assholes. It's hard to build systems that work for the people you have and maximize talent. Do the hard work.
4. Change and respect are earned through success. If you follow my advice, you will start with odd and ugly processes. The Project Management Office and other managers will laugh and criticize you for nonstandard practices. But as you succeed, you will earn the right to convince others to buy into a better way. Find a way to finish, then start optimizing.

Originally published on willhea.com.