If this is over email, I always start with the "ask" first and then follow up with the most important information:
"I'd like your approval to move the validation job to a new server. It will only take one hour but will save Dave many hours a week cleaning up the jobs." Then go on to explain the details.
Nobody wants to read a long email to understand what it is you want them to do. 9 times out of 10, they'll provide the ask and only read the details if they need to.
Deductive or BLUF - bottom line up front. Maybe this issue is obvious and so the only thing the reader needs to read is the first line. Deductive saves them time. Deductive also gives the reader something to think about while reading the rest of the argument.
The alternative is inductive which gives evidence and then concludes with a conclusion. You're torturing your reader by dragging them several paragraphs into the deep.
I usually write inductive as that is the way I think and then refactor into deductive as that is the best way to persuade. (I note that I wrote this inductively.)
Yeah but the author's message is... Problematic. Warping the way you talk because of a creepy manager/engineering culture is not healthy.
Anyway the engineers don't say 'this would take an hour to fix and it's worth X to do it'. It's all intuitive! 'this is really annoying so the team agrees to do it soon'. It's not about being a perfect utilitarian robot it's about being productive and having a good life.
I am a big believer that all approvals are bad. All they do is add wait time and bottlenecks with people who are further from the problem. I think they are a symptom of poor risk mitigation.
code reviews are a discussion and my one exception.
I believe in a balance. Spending 1 hour for the task mentioned in the article is something that should just be done without having to ask for approval.
But knowing what to do and when to ask for "approval", requires that we are aligned with the business, so that we can make these decisions in the context of "the greater good". If not, the business may decide to take away these privileges and start micro managing.
I wish our management understand that. Even getting basic cables and adapters can be a kafkaesque battle that requires endless justification. I never thought that this is what it would be like working at a FAANG. Fwiw, I worked at different FAANG and they had a self serve kiosk with free cables and adapters. It was way more efficient.
It may just be a fake scenario but the actual solution there would be to implement the 1 hour fix without a single discussion or email.
Sometimes the best way to tailor words for both engineers and managers is to 1) solve the problem then 2) if the solution was actually difficult, explain how you solved it in simple terms.
Is it common for people to describe servers as "weak" and "strong"?
I haven't heard this before, and when I was reading this initially I thought this example was going to be the example of tailoring words for non-technical managers.
In my experience both as an engineer and a manager, the engineerspeak is not always as simple as the example here (which in itself is overly “explainy”). Many engineers have a tendency to over explain and provide too much detail to management. I know I was guilty of this once. Ultimately what you think is a reasoned and simple argument in favor of a proposed changes just becomes a jumbled mess of meaningless details.
You don’t need to dumb it down and manipulate anything—just be brief. Brevity and sticking to facts are key.
- One of the two servers has disk space issues
- Using the low space server for these jobs is costing us a productivity time loss for our engineers who have to manage the low disk space issues
- we would like to move some jobs to the other server to eliminate the cost of managing the disk space.
- there are no hard costs associated with making this change, only savings.
Author here. There are some managers that do need such babysitting, particularly if you are in a non-tech industry.
Thanks for the comment. I realized I didn't mention when this kind of tactics might be useful. Added the following paragraph to the end of my post:
> At this point, you might start to wonder: What kind of incompetent managers deserve this degree of babysitting? They probably don’t in the tech industry, but not every engineer work at a tech company. They might be in retail, fashion, film production, etc., where there just happened to have a need for software development. Even those who do work in tech might wish to move to an industry that is less tech-centric, at which point these communication skills will prove handy.
Where is the post doing that? Where it lists the people impacted? Where it implies (but doesn't explicitly assert) that the disruption is enough to impact their ability to meet deadlines?
"I'd like your approval to move the validation job to a new server. It will only take one hour but will save Dave many hours a week cleaning up the jobs." Then go on to explain the details.
Nobody wants to read a long email to understand what it is you want them to do. 9 times out of 10, they'll provide the ask and only read the details if they need to.