It is PI planning time.
Another PI, another passionate plea for time to refactor the BillingService. You say, “We need to prioritize a refactor of the BillingService. It’s brittle, hard to change, and it slows us down”
Heads nod, they hear you. You get excited . . . maybe this will be it. Maybe this will be the PI where the refactoring gets prioritized. And the Product Manager opens his mouth, and you know you have lost. He pulls up the roadmap. He says, “I hear you, but we have three new features we’ve promised to deliver. Refactoring doesn’t add any direct customer value, we will have to defer to next PI.”
And the wind was just removed from your sails. How much longer can you tell your team, that the refactor that they are all screaming for, has been kicked down the road, into the gutter, and ignored.
So why did you lose? You lost because you walked into a business meeting, with feelings and emotions. You told them that the code (that your team wrote) is brittle. They heard “a black box of cost with no measurable ROI.” If only the Product Manger wasn’t there . . .
To win this argument, you need to make your pain theirs. You need to translate your “feelings” into their language: quantifiable risk, impact to delivery.
During your next PI event, imagine this scenario:
This time, you connect your laptop to the display, then you open a dashboard.
"This is the dependency graph for our BillingService," you begin. "This isn't my opinion. This is a statistical analysis of our last two years of Git history."
You point to the screen. "The BillingService is in the 95th percentile for risk. It's a known hotspot. But that's not the real problem. The real problem is its blast radius."
You point to the screen again. "Every time we change the BillingService, there is a 78% statistical probability that we will also have to change the InvoiceGenerator. That's not a guess; it's their co-change correlation."
"Worse, the InvoiceGenerator is a critical risk in its own right. And its bus factor is one—only a single active contributor."
You click on another node. "And this is the nightmare scenario. The BillingService is deeply coupled to the LegacyAuthService, a component no one on the current team has ever touched. A 'simple' change in billing has a direct, statistical link to breaking our entire authentication system."
You close your mouth and look around the room. You have come out swinging; with data, not feelings.
People have stopped answering emails, they are ignoring the Teams notifications. The temperature in the room has changed. The conversation begins, you have overcome the “engineering feeling vs. business feature” argument. Now you are having a conversation about risk.
The Product Manager is looking at their roadmap, they realize that this PI was going to dance through the minefield that you just mapped out. The lightbulb comes on . . . all of a sudden, simple isn’t so simple.
Congratulations
You have just turned an “emotional” opinion, into cold hard facts. The cost of not doing the refactoring is now visible to all. The risk of breaking Authentication is clear. The realization that if “Suzy” gets hit by a bus crossing the street, then the BillingService won’t get enhanced. And the potential costs of misreporting taxes due to regression in the tax calculator are now clear.
This is how you win. You don’t ask for blind faith. You ask for faith in the data. You show the data, you show the history, you show the mess that your team has to deal with.
You learn a lesson. The next time that you have a “critical” refactoring that is going to be punted to the next PI, you bring data; not emotions.
Ask your Product Manager a question they can’t ignore: Which of these new features are you willing to sacrifice when this high-risk BillingService inevitably takes down our production environment for a day?