I bet you know that one guy from work: They treat every meeting like brainstorming. They are super smart, think fast, know a lot, and throw out suggestions on the table as Eureka hits. You admire their intelligence, but at the same time you fear that they might drive the discussion off-topic and even derail project roadmaps.
With their presence, a typical sync-up meeting can go like this:
You: “I have wrapped up Module A last week. In this sprint, I’m building Module B.”
That one guy: “Hey what do you think of adding a feature X to Module A?”
Things can unfold in several ways, each with its drawbacks:
- Treating it as an order implies a lack of task prioritization skills.
- Spending time researching the suggestion, while low-effort, is still a distraction.
- Flat-out rejecting the idea may come off as abrasive.
Enter the fourth option: ask the proposer to do their homework.
In lawyers’ world, there’s a concept called “burden of proof”. It refers to the expectation that whoever put forward a claim must present proof. For example, if you say Alice stole from Bob, show a photo of Alice trying to sell Bob’s Rolex. Similarly, at work as software engineers, whoever suggests a feature request should bear the duty to show that such need exists.
Back to our imaginary meeting. Here’s a constructive response:
“Sounds good. When you are done implementing X as a microservice, shoot my an email, and then I can invoke its API from my program.”
Avoid inviting them to modify the code you’re working on; imply strongly that you want them to build a standalone application that is separate from your work. This reduces the risk of them breaking your program and — even if they managed to implement X — gives you a hedge at the verification phase to politely decline the integration.
The said intellectual should get the nudge. However, even with this approach, they may fail to read the air and say something along the lines of:
“I meant to say YOU should go build it.”
That’s high time you should provoke some thoughtful examination on the timeline and original design. Some possible responses include:
- “Which product requirement would X satisfy that neither A or B is going to cover?”
- “What additional value will X provide to the users?”
- “Has anyone asked for X yet?” or “I can think about it when there is actually someone asking for X.”
I believe this is the right attitude to deal with change requests that pop up randomly during meetings which will derail the conversation. Embracing this approach cultivates a mindset that effectively handles spontaneous change requests during meetings, safeguarding discussions from potential derailment. “Burden of proof” ensures that ideas undergo thorough scrutiny before becoming integral components of your project.
