The Hardest Stakeholder Is the One Who Used to Code
How I said no to a university director who was sure it was a five-minute change.
When I was Product Lead at CAMU, our university management platform, one client stood out. The university director had started his career as a software developer. He knew just enough about how software works to be certain about how ours should work.
His request sounded reasonable: “Let me edit the class time slots whenever I want.”
Here’s the setup. In CAMU, an institution defines its class slots once in configuration: Slot 1 is 09:00–10:00, Slot 2 is 10:00–11:00, and so on. Every weekly and monthly timetable is built from those slots. Not copied from them. Built on them.
So when he said “just make it editable”, he was picturing a settings field. What I was picturing was this:
Change Slot 1 from 09:00 to 09:30, and the system doesn’t just change tomorrow. It changes every timetable that ever used Slot 1. Last semester’s classes would suddenly show times they never happened at. Attendance records would no longer match the class they were marked against. Exam schedules could shift or clash. And the audit trail, the one thing a university needs to be able to defend, could no longer be trusted.
Why the “technical” stakeholder is harder
With a non-technical stakeholder, you translate tech into business. With a former developer, you face a different problem: he already has a mental model, and it’s wrong in a confident way.
Get Kishor Vanja’s stories in your inbox
Join Medium for free to get updates from this writer.
“Make it editable” is trivial — as a UI change. The complexity isn’t in the screen. It’s in what the data means over time. So I didn’t argue features. I spoke his language.
How I made the case
1. I showed him one real record, not an architecture diagram.
I pulled one student’s attendance from the previous semester and asked: “If Slot 1 becomes 09:30, what time was this student present?” There was no good answer. That single question did more than any explanation.
2. I named the problem in his terms.
To an ex-developer, “this is shared reference data, and history points to it” lands instantly. He’d have rejected the same design in his own code.
3. I made the cost about him, not us.
Not “this is hard for engineering.” Instead: “If an exam result or attendance record is ever challenged, your university can’t prove what actually happened.”
What I offered instead
A “no” with nothing behind it just moves the fight to the next meeting. The real need was valid: schedules do change between terms. So the answer was to separate changing the future from rewriting the past.
New slot versions take effect from a chosen date. Everything before stays frozen. He gets his flexibility; the university keeps a record it can defend.
The lesson
Saying no to a tough stakeholder isn’t about winning. It’s about finding the one question that makes the risk visible to them — and then giving them a better yes.
The director didn’t need an editable field. He needed control without consequences. Those are very different features.
Have you had a stakeholder who knew just enough to be dangerous? How did you handle it?
