Killing Software Projects with Modal Verbs

Modal verbs are the words that express a degree of certainty, like: may, can, will, shall, must. You see them in RFCs all the time:

1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.

In the old days, software analysts would descend from mountain peaks with reams and reams of software requirements arranged in three-ringed binders. These requirements also came with words like "must" and "may". After a couple months, developers would repurpose the binders as doorstops and monitor risers. 

The days of thick binders are over, thank goodness, and the days of more frequent face-to-face communications are here. The communication has to be obvious and lucid in order to work, however. Analysts were good at using the "proper" language to shape results. The same decisiveness has to come across in today's whiteboard and water cooler discussions.

What the tech lead says: You may want to possibly refactor that class.

What the junior developer hears: The code is gold!

I've been in conversations where the words "may", "maybe", "perhaps", and "might" dominate the discussion. These discussions are never productive, and make a leader or expert appear indecisive and unconfident.

From Hacknot:

A Technical Lead lacking in self-confidence can be a major frustration to their team. They may find themselves waiting on the Lead to make decisions that significantly effect their work, but find that there is some reticence or unwillingness to make a firm decision. Particularly when new in the role, some Technical Leads find it difficult to make decisions in a timely manner, for they are paralyzed by the fear of making that decision incorrectly. Troubled that a bad decision will make them look foolish, they vacillate endlessly between the alternatives, while their team mates are standing by wondering when they are going to be able to move forward.

You could substitute "domain expert", "product manager", or "stakeholder" for "technical lead" and the paragraph still makes sense. Many times the problem isn't timely decision making but ineffective communication. Maybe that's just the individual's personality. Perhaps they are just being politically correct or may be timid.

What the stakeholder says: The last change we might want to possibly make is to change this screen to maybe make the buttons stand out a little more.

What the developers hear: We are done! Ship party!

It's perfectly fine to be an expert and say "I don't know", or "this requires some research", but when possible you need to paint the world in shades of black and white to keep a team moving towards the goal.

You must make decisions.

You must clearly communicate those decisions.