If you’re a developer you’re going to spend a good chunk of your days arguing the merits of different approaches. In a healthy organization it works something like this:

  1. Developer has an idea for a fix or improvement.
  2. Developer writes down the idea as a proposal.
  3. Team meets to discuss idea. Objections are raised if there are any. The developer gets a chance to address those objections.
  4. Idea is either approved and added to the project according to priority or not approved.

In a world of rational robots this workflow could be trusted to continuously run perfectly. With humans there are many points of failure.

  1. The developer’s idea is too vague or too large to be implemented. This is a common problem for journeyman developers. They want to improve things, but don’t have as much direct experience so they’ll often request large sweeping changes. This is the classic “Let’s rewrite everything in Rust!” Or “we should write more functionally”. And when asked for specific examples the developer can’t really come up with any. Requiring proposals in writing makes this much more obvious.

  2. There’s no process for acceptance criteria. Many teams have no formal process at all for prioritizing or defining new features. Ideas are brought up in meetings but no follow through occurs. Teams without the discipline to follow through on shipping features typically devolve into firefighting. Errors in production remove any need to prioritize or think long term and for that reason are psychologically much easier to handle. However, the toll of working in a team like this is a recipe for frustration and burnout.

  3. All team members need to be persuadable by evidence. If you’ve ever done jury duty in the United States you’ll remember being told over and over again that you must leave your biases at home and consider only the evidence. This needs to be the rule for approving or denying new features. If you’re presenting the idea, bring evidence. This should sound like “70% or our production issues in the last three months are caused by this condition (include links) and if we update this code to do this (with pseudocode example) we can eliminate that class of error.” And if you’re on the team reviewing the idea, your objections have to sound like “How would your solution handle these common error scenarios that we see often? How would it affect current workflows for users and support?” Less productive teams will devolve into relying on status or hyperbole in these discussions. This is especially dangerous because it tells developers that their ideas are not judged on merit, but other considerations outside there control. The chilling effect on initiative taking can’t be understated.

  4. Project management ignores feature proposals. Some managers treat their work as taking whatever they heard at their last meeting and shoveling it off to the dev team to figure out. In these places no amount of evidence will overwhelm “VP ‘X’ says AI is the new thing so we’re going to be building a chat bot this sprint.” Skilled managers who can push back and keep priorities straight are rare, but they will earn fierce respect from their dev teams. And they’ll be rewarded with highly productive developers who can ship.