Talking with Engineers - A Guide for CSMs, Support, and Product

CSMs Perspective

You've just had a question from one of your customers, a tense call and through the corner of your eye you see an elusive software engineer with big bulky headphones on, what do you do?

Roll Initiative!!!

You approach the engineer and wave your hand in front of their monitor to get their attention. I mean, the customer's question is important, so the disruption is justified, right?

The engineer sighs loudly, reluctantly takes off their headphones, and takes a deep breath. Finally, they turn to you and say; "What can I help you with?"

You reply to the engineer with, "I just got off the phone with Jeremy from Chips N' Fish, they were having a little problem with the platform."

An unsettling silence becomes apparent while you have an expression of hopefulness on your face and await a courteous reply from the engineer.

"What's the problem." the engineer asks.

"Well! Thrilled you asked! They were using the system to create a new product in their inventory, and it didn't work!"

A slightly longer silence continues while you await another courteous reply from the engineer…

"You're gonna have to give me a bit more information about that… What exactly happened, were there any errors?"

You feel a tad raw due to the discourteous reply you received from the engineer, but to hell with it! But you believe the customer’s inquiry is critical, so you press on!

"Well, they were discussing the details of the product with their colleague Mary. Mary has a cute daughter named Alice, she's into game development." you reply.

The engineer doesn't respond, but just stares at you.

You continue, "After they filled out the product details, they tried to save it, but it didn't save the product."

"Was there a dialogue that popped up when they clicked 'Save'?" the engineer asks sharply.

You respond expertly with "Yes. The dialogue said 'Token Invalid'"

"How long did they spend entering the product details before they saved it?" the engineer replies.

Puzzled at the relevance, "Uhh, I don't know…" you reply.

"That form is protected by a CSRF Token, if the token is not used within 15 minutes, it will become invalid and the customer will have to start over." the engineer replies.

"That's a bit silly, don't you think?" you respond to the engineer. I mean, you're not wrong in the slightest bit.

"It was a product decision and part of the acceptance criteria." the engineer says as they put their headphones on and return to their work.

What's the Problem with this??

Well, in short, there is no issue with the question or problem, it's a perfectly valid inquiry. The issue?

What we engineers call "The Fluff", which is a technical term that indicates "All of that irrelevant information that serves no benefit to the inquiry but acts as pleasantries".

We engineers don’t intend to be rude, our roles require us to value efficiency as it takes a lot of time and focus to write quality and functional software. Each interruption we have creates in unproductive time wastage spent 'trying to get back into the flow of what we were working on prior'.

I can say from experience, many engineers have had conversations exactly like the one above, and they are probably a little pissed-off with me for posting it.

Engineer's Perspective

You are focusing deeply on the task at hand and making great progress refactoring some complex and illegible logic into sweet ubiquitously named self documenting methods.

Suddenly, a hand is waving in front of you between your monitor and eyes.

What the heck is that? Is this some severed hand waving at me? Shoot, what was I doing again? Oh!it's CSM… I'm wearing big, bulky headphones to indicate that I'm flat out and shouldn't be interrupted.

You let out a slight sigh as you remove your headphones.

"What can I help you with?" you ask.

You think to yourself, I really hope this is fast. I have so much work that needs to be done, product have been riding my ass, and my partner is upset with me because I keep working late and on weekends just to get things done.

"I just got off the phone with Jeremy from Chips N' Fish, they were having a little problem with the platform." they answer.

You want to reply sarcastically with "well that's a lot of helpful right there that is", you understand that CSM are trying their best; that helps you to respond in a more constructive way.

"What's the problem?" You reluctantly ask, trying to cover up your increasing sense of frustration.

"Well! Thrilled you asked! They were using the system to create a new product in their inventory, and it didn't work!" CSM reply.

You think to yourself, it's been 1 minute so far… And I have no idea what the heck is actually happening… Get to the point, friend!

Letting just a tiny bit of your inner frustration out, you say, "You're gonna have to give me a bit more information about that… What exactly happened, were there any errors?"

"Well, they were discussing the details of the product with their colleague Mary. Mary has a cute daughter named Alice, she's into game development." your friendly neighbourhood CSM responds.

You stare blankly at CSM…

"After they filled out the product details, they tried to save it, but it didn't save the product." CSM Continues.

With a bit of information about where the customer was when they experienced an issue, you reply with, "Was there a dialogue that popped up when they clicked 'Save'?"

"Yes. The dialogue said 'Token Invalid'" CSM Reply.

"How long did they spend entering the product details before they saved it?"

"Uhh, I don't know…" CSM Say.

You remember that a recent change in product criteria set to introduce CSRF Tokens to all Create and Modify forms throughout the web application.

"That form is protected by a CSRF Token, if the token is not used within 15 minutes, then it will become invalid and the customer will have to start over." you inform.

"That's a bit silly, don't you think?" CSM snaps back in a seemingly pseudo-witty way.

For a split second, your thoughts turn to bludgeoning CSM with your keyboard, but instead you begrudgingly reply with "It was a product decision and part of the acceptance criteria."

Knowing that you've just wasted your time with a non-critical question that instead could have been asked via instant messaging or email. In frustration, you put your headphones on and now have to get back into the thought process to get back onto the task you were working on.

Effective Communication is About Respect

In our scenario above;

• The CSM thinks the engineer was rude and obnoxious.
• The engineer thinks that the CSM was unnecessarily disruptive and disrespectful of their time.
• The engineer now has increased pressure due to the interruption and time loss.
• Both the engineer and the CSM feel annoyed with each other.

On average, it takes engineers around 30–45 minutes for their productivity to recover after an interruption. This results in more bugs, less overall engineering efficiency, and greater pressure on engineers to work extra hours to make up for the lost time.

So how can this be improved? Allow me to introduce you to;

BLUF: Bottom-Line Up Front

The concept of BLUF stipulates that, the most important information should be the first thing communicated in the BLUF communication paradigm.

In our given scenario, that would be. "The customer received an error saying 'Invalid Token' when trying to create a product in the platform."

Notice how the particular details of the customer, their co-worker's daughter, and all the non-vital "fluff" is stripped out?

The engineer has exactly enough information to begin troubleshooting and in this circumstance will likely respond with "We added CSRF Tokens to that form, you'll need to find out how long they had that page open for as that error indicates the token timed out."

Given that the request isn’t actually that critical, it probably doesn’t warrant an interruption. In this circumstance, an email or instant message will likely be sufficient.