20 (Or So) Things Managers Should Stop Saying To Engineers

Patroklos PapapetrouOctober 2nd, 2014Last Updated: October 1st, 2014

5 25 4 minutes read

This post is a direct reply to an article I recently read with title : “20 things engineers should stop saying‘.I was so frustrated and irritated when I finished reading this article that I couldn’t believe in my eyes. I still wonder what kind of manager is suggesting these ideas and how their engineer would react after reading this post.

All these 20 “evil” engineer phrases are not at all “technobabbles” and they are so clear that even a first year student would easily understand their meaning. Which part of that sentence don’t you understand:”What’s the ROI of that feature?” To be honest this is a question that managers should as before dropping ridiculous requirements to the dev team. You should feel really lucky that you have engineers asking such things! Moreover, some of them look so weird to me and I’ve never heard of them the last 16 years I’m working with software development teams so I’ll try to figure out what do they mean.

But the most important question for me, is when and why an engineer are forced to say those “terrible” and “pissing” stuff. Let’s take them one by one, side by side with the root cause of each sentence (in bold) alongside with some comments of mine:

We don’t work against dates:
“I’ve promised to the customer that everything will be ready by 25th of December. Now we need to talk about their requirements.“
Of course we don’t work against dates when we don’t have a fixed scope.
We need more resources:
“You two guys will build,test,deploy and support our new ERP system“
Quality, speed, cost — pick two. It’s Friday afternoon:
“I wanted all these features customer asked it until Monday but we can’t afford to pay overtime. Oh I almost forgot it. Please keep the quality of the project (unit tests, complexity, coding rules) at the highest level. Besides, it’s your responsibility!“
What’s the ROI of that feature:
“One customer out of thousands wants a “tiny” and “cool” new feature that will send him a notification when it’s time to pickup the kids from school“
…Meh…
We don’t need reporting:
“I want to get every week an excel in my inbox containing a detailed report about your activities“.
Wake up! There are plenty of ways to track developers work and definitely “reporting” is not the right one.
The customer really doesn’t mean that:
“Customer wants that the system to popup an alert every time they press the letter ‘A’ instead of the letter ‘S’“.
They can use the command line:
“I ‘know’ that you have more important things to do but can we implement by tomorrow a screen with some nice buttons and instructions so that customer can trigger the weekly report in pdf format?“.
They can use the API: See #7
You wouldn’t understand. Actually the correct is: ”You don’t even try to understand”, or “You don’t want to understand”.
“It’s the 3rd time I ask you why it’s so hard to write bug-free software according to what the customer wants!“.
Note: Nobody knows what the customer wants, not even the customer!
That’s a nice-to-have: See #4
We tried that before:
“Can you please integrate their ‘legacy’ system with our ERP? I know they don’t provide any way of accessing their data but you’re the experts, right?“
I don’t understand the requirements (have you read them? no):
“Why it’s so hard to write code based on customer requirements. You can find them in my hand-written notes taken when interviewing some end-users, in the last 6 emails I sent you and in a google document I shared with you!“.
99% of these “requirements” are controversial and lack clarity.
Technical debt:
“I don’t want to hear anything about code quality. Just throw some code here and there to make this work!“
Seriously? You don’t want engineers talk about Technical debt? And even worse, you don’t understand what technical debt is?
Can you QA this? – Ok maybe this one is somewhat not clear. Does “Can you reproduce that?” make any sense?
“Customers claim that the system, randomly, with no obvious reason, doesn’t allow them to delete an order!“
It’s not a bug, it’s a feature:
“I know we haven’t discussed it yet, but can you please add a double confirmation dialog box when users delete a customer record? We need to fix this bug A.S.A.P.”
That violates the CAP theorem . OK, this one and the following are the only sentences that can be considered as “obfuscating”:
“Our new enterprise platform is going to be used by thousands of clients via web service invocation. So it’s really important to achieve 100% availability, data consistency and at the same time it continues operating even with arbitrary message loss.“
Rube Goldberg:
“Let’s build a a calendar application that uses a distributed NoSQL database, soap & rest web services, elastic search, HTML5 responsive design, Node.js, SPRING MVC and many more ”
Does KISS (Keep It Stupid Simple) make any sense to you?
That’s the platform team’s responsibility:
“Can we add a caching mechanism when fetching data from DB?“.
This is a totally valid reply when there are in-house developed libraries and frameworks that consist the “platform”. Usually in such cases companies have a dedicated team to maintain the platform.
It will take 30 points:
“How long it will take to implement this feature?”
Why “It will take one week is more meaningful to you?” Because you will pull trigger if it’s not ready at the time promised? What about technical difficulties that might occur? Random tasks that will delay me? or any other external factor that will make me lose some time? 30 points is a very decent answer. Would you prefer something like: ”This feature is 30 pounds heavy?” What I tell you is that I can estimate the size of this feature based on my previous experience but I can’t guarantee the delivery time. Is this is so hard to follow?
Why would we do that? (See #4 or #6)

Now that you’ve read a developer’s point of view who’s the winner? Manager or Engineers? Nobody!! Both of these sides should try to understand each other and come to a common way of communication. They are not enemies? They share a common aim which is (or should be) providing working and useful software for end-users / customers.

Reference:

20 (Or So) Things Managers Should Stop Saying To Engineers from our JCG partner Patroklos Papapetrou at the Only Software matters blog.