The Workplace Stack Exchange is a question and answer site for members of the workforce navigating the professional setting. It only takes a minute to sign up.
Sign up to join this community
“Developers need to be informed the scope, timelines, and other expectations that are material to the success of needed changes.”
This statement was made by a developer to an executive, a non-developer, who directed the work of developers in the organization.
“Developers need to be informed the scope, timelines, and other expectations that are material to the success of needed changes.”
More just a statement of fact.
the scope
Say that you said you told a chef you wanted "egg for breakfast." You might end up with anything from a single soft boiled egg (3 min to make) to a full omelet. Why? Because you made a request without providing the scope.
In software terms, say that you asked for a program to let you type documents. You could end up with anything from Nodepad to Word to perhaps even Microsoft Paint as it does let you generate documents if just by cutting and pasting stuff around.
timelines
We need to know when you want it done by so we can have it done by then. If you want feature A before feature B so you can show the client feature A first, the developers need to know so they don't start work with feature B.
other expectations
As brilliant as we are, we cannot read minds. Sorry.
If you end up on a team where developers don't ask for/get this from management, you have a team of developers who are so demoralized that they have stopped caring how the project turns out. Your project is doomed or if it does make it to the end, will be quite fragile and/or useless.
Viewing this as an "adversarial" statement is absurd.
Whether or not it is absurd is irrelevant if they are your manager. If they are your manager, I recommend just sitting back and letting the mess that attitude causes be made while you job hunt. Some people just like to be in charge and if they sign your paycheque, well, you let them.
This sounds to me like something that was said during some sort of debate where the developer is angry or frustrated for not being told something that they (probably quite rightly) needed to be informed about before a work item was done, but wasn't. There are definitely better ways to frame the argument however.
Consider the setting. If that was written in a technical specification and included in the context of a technical audience then no, it is not adversarial, it is simply setting expectations.
HOWEVER - if the VP is not a technical person, when you factor in the fact that they don't necessarily have an understanding of what developers need to know, being told quite so bluntly that it was, in the developers eyes, the VPs fault that the developer hadn't known to develop x or y, then yes it could be considered to be somewhat adversarial. But then - if the exec is not a developer, would it be reasonable to expect a non-developer to know this?
I don't know what constitutes an "adversarial statement" in your region of the world or what consequences such a statement has. But I can tell you why the executive is so angry about what you said or wrote:
Developers need to be informed the scope, timelines, and other expectations that are material to the success of needed changes.
This is not a statement of fact. As such, it would be blatantly false. Developers can work without those, it's just that the quality of their output will degrade significantly. What this is, is an order. It needs to be done, no alternatives. The correct answer to that sentence would be "Sir, yes, sir!"
Lets try this again being less commanding:
Getting information about the scope, timelines, and other expectations that are material to the success of needed changes will significantly improve the developers output.
And maybe if you want to insist:
To meet the given deadlines and quality standards, improving our output is necessary.
What is the difference? Well, in the first case, you took it upon yourself to play executive and already make that decision that improved output is favorable compared to the costs of getting the information across. Then you commanded your boss to take the decision you deemed right. The second version is taking the facts and giving feedback and leaving the executive decision to the guy that actually is the executive. Maybe it's worth the cost. Maybe not and the deadlines are too tight? Maybe something else altogether, hire more people, outsource, not take the project on, whatever else could be done. Making those decisions is the job of the executive. Not yours.
The point is: you played boss. You tried to boss your boss around, tell them what you need done instead of telling them what options they have. Bosses don't want to be bossed around by their reports.
