By Tammy Baker
Welcome to Truth in the Trenches, a new Parking Today column about the evolving world of parking operations, where client experience, team dynamics, and everyday decisions meet the future of mobility. My goal is to unpack the real effects of new trends, old habits, and daily choices and to offer grounded, useful takeaways for those of us who keep operations moving.
Why this matters
Parking and curbside management are no longer just paper, pavement, and striping. They’re deeply tied to how people move, how cities grow, and how technology reshapes expectations and service delivery. This column is my commitment to exploring how these changes affect people getting things done across organizations.
Every city I enter is selling the future: sensors, apps, cameras, artificial intelligence, promising to make operations “smart.” But beneath the talk, I keep seeing the same issue: We design for when everything works, not for when it doesn’t. How we respond to what breaks determines whether technology helps or hinders the people who depend on it.
There’s often pressure to “just get the solution built.” We don’t have time to plan for what could break; we need to get the new plan in place. However, the best time to think about what could break in the new plan is before it’s finished. The time to plan for backup and quality control isn’t after go-live; it’s when your product or process is about 20% to 40% complete.
That may sound early, but at that stage you still have room to influence design and allocate resources. Waiting until everything is “baked” means layering on fixes instead of incorporating resilience from the start.
Designing with the full picture in mind
Taking time to think through the entire process, from ideal launch to worst-case failure, saves time, money, and stress in the long run. The rewards include:
• Early identification of “gotchas.” You catch what’s missing before it costs you.
• Better prioritization. You can rank features and fixes by their real impact.
• A more robust initial offering. You go live with fewer weak spots.
• Built-in redundancies. When something breaks, continuity is already planned.
• Higher stakeholder alignment. Everyone understands expectations and recovery paths.
This kind of thinking doesn’t just protect technology; it protects people. It prevents burnout among staff reacting to emergencies and frustration among users who expect seamless service. Ultimately, it builds credibility.
Mapping the “what if” scenarios
When you take the time to map possible failure or quality issues, you’re forced to visualize how your system behaves under pressure. That exercise exposes process gaps and decision points that might otherwise be missed. Once those are visible, you can fold them into the development roadmap intentionally.
Compare that with the opposite approach of waiting until something breaks, scrambling for a workaround, and patching the system after hours. One path is proactive; the other is chaos management. Both take effort, but only one gives you control.
Bringing others along
Seeing the full picture is one thing; helping others see it is another. Although you might raise concerns, if others are buried in their own priorities, they might not see why your “what if” deserves attention now. Often, what separates ideas that move forward from those that don’t isn’t the idea itself; it’s how it’s communicated. Are you framing your concern as an obstacle or an opportunity? Are you leading with the problem or the potential outcome?
People a few layers removed from daily operations may not grasp how a small decision affects workflow or customer experience. It’s your responsibility to make those connections visible, to translate what you see into something that matters to them. Bring data if you have it. But also bring a story, one real example or plausible scenario that shows what could go wrong and why.
When you position yourself as a partner helping to protect the project, rather than simply someone flagging risks, you gain credibility and support. Over time, you become the person others seek for foresight, not just feedback.
Here are a few ways to do that:
• Show the cost of failure. Quantify downtime, client frustration, or revenue loss. Numbers open ears.
• Map ripple effects. Visually connect one failure to multiple stakeholder pain points — for example, a sensor outage leading to enforcement confusion, client calls, and revenue disputes.
• Recruit an ally. Find someone whose success depends on getting it right: an operations manager, IT lead, or client contact. Their endorsement carries weight.
• Make your request specific. “We need two hours to map recovery steps” is actionable. “We need to talk about quality control” is not.
Closing the loop
Smart cities aren’t built by technology alone. They’re built by people who see how systems fit together, people who think through both success and failure and bring others along in the process.
So, here’s your Truth in the Trenches challenge: Before your next project hits the halfway mark, take one hour to map three things that could go wrong and one step you could take now to prevent each. Then share that map with someone outside your immediate circle and ask for their perspective. You might be surprised at what they see or what they’ve never considered.
Seeing the full picture isn’t just foresight; it’s leadership. And leadership, in the trenches, starts with the courage to ask, “What happens if this fails?”
Tammy Baker is the chief operations officer for Parker Technology. She can be reached at [email protected].
