When Your Gut Is Telling You Something, Listen
There are moments in a program manager's career when following the established process is exactly the right call, and moments when following it blindly leads to serious problems. Knowing the difference is not something any methodology teaches you. It comes from experience, and sometimes from a project that goes sideways before it gets right.
I was once tasked with leading an ADA compliance initiative for a company's primary application, covering web, mobile, and Smart TV platforms. Accessibility work is not optional. It is a legal and ethical obligation, and the stakes of getting it wrong extend well beyond a missed deadline. When I assumed the project it had already passed through the hands of two product managers, both of whom had moved on to other opportunities. I was inheriting something that had already lost momentum and institutional memory. I did what any program manager would do in that situation: gathered what information I could, held a structured kickoff meeting, aligned the team on tasks, and built a plan around the information available.
What I did not yet know was that an outside agency employing visually impaired users had already conducted a formal evaluation of our applications across platforms. Someone had commissioned that work. The findings existed somewhere. But I could not locate them through any of the documentation available to me. Following protocol, I brought this to the product manager and asked him to reach out to the agency directly to obtain the results, since their findings would be essential to shaping our development work.
Week after week I followed up. Week after week I was told the agency had not responded. My manager, reasonably applying the boundaries of role definition, instructed me to stay out of it. Outreach to external partners was a product management responsibility, not mine. I understood the reasoning. I also could not shake the feeling that something was wrong.
When the product manager was out on leave one day, I made a decision. I contacted the agency directly. Their response came back almost immediately, and it was pointed. They wanted to know why, after commissioning an evaluation of our platforms, we had gone completely silent. From their perspective they had done the work, delivered value, and been ignored. I spent considerable time repairing that relationship, explaining the project transitions, and assuring them that their work was valued. To their credit they responded professionally. They shared their findings, and I organized a call to review everything in detail with the relevant teams.
What they surfaced was significantly more extensive than our original scope had accounted for. There was considerably more work ahead of us than anyone had planned for. I pulled together the cross-functional teams, restructured the plan around what we now actually knew, and drove the effort through several sprints. We completed the work by the end of August, right at the deadline. It was not a comfortable delivery. It required concentrated effort, difficult conversations, and a degree of urgency that a better-managed handoff might have avoided.
The lesson I carried out of that project was simple but important. When your instincts are telling you that something is wrong, especially on work that has real consequences for real people, you have a responsibility to act on that signal. Process and role boundaries exist for good reasons, and respecting them matters. But no process is a substitute for professional judgment, and there are moments when stepping carefully outside your defined lane is not insubordination. It is leadership. The key is to read the situation clearly, act with transparency, and be willing to own the outcome. On that project, I was glad I did.
