Engineering communication

Couple of years ago I was at an offsite with Christopher Avery “The Responsibility Process Guy” where I learned a lot but one thing really really stuck with me. He  warned us about avoiding questions such as

What is wrong with me?

What am I doing wrong?

What did I do wrong?

Mostly because our minds will work on finding an answer and providing that is likely what you need. Sometimes you ask “What is wrong with me?” when you misplace your keys and that question won’t help you find them.  Instead, you should be asking “when did I use them last?” or “where could they be?”.  Rather than “What did I do wrong?” try “What could I have done better?”

I have also discovered that engineers are always seeking answers and solutions.  When I connected the two, I started monitoring and experimenting with my team. 

The experiment was nothing more than a manager trying to get the proper answers from his team. Quickly I learned that the answers could vary depending on how you ask the question.  The great thing about engineers is that they are smart and they catch on to you fast!

Here is an example of a conversation that I witnessed.

Manager: Where are we with this feature implementation

Engineer: Hard to tell, somewhere between 50 and 80% 

Manager: That is a big gap, why?

Engineer: We don’t have the full requirements

Manager: But we need to communicate when we will be done

Engineer: Oh, well next release

Manager: Really?  But I thought we don’t know what is left

Engineer: Oh, I was just trying to give you an answer and I know it can’t be this release

Another example of a type of conversation we hear often

Director: The customer is threatening to leave us unless we fix this issue, can we hotfix this change tonight?

Manager: we can :|

If your goal is to always get what you want out of your engineering team, then I have given you the weapon. If not, make sure you ask the questions that create a conversation. This is one of the reasons why the scrum master job is becoming more and more important.  It is also why scrum master training is essential for every engineering manager.  Scrum Masters are trained to ask the right questions and facilitate different type of engineer meetings.

As far as giving wrong or fast answers, I had to learn the lesson very early on as a manager, that saying “Yes it could be delivered in that time frame, but it is risky” is the same as saying “Yes”.  This is where answering a question with more questions is appropriate and possibly necessary.  Questions that could help get your engineers on the same page with your business stakeholders - 

“Why do you need it by this timeframe?”

“What are the must-have and nice to have in your ask?”

“What are the resources at my disposal?”

“Why can’t we ...? Or Why?”

Before you get to ask these questions, you need to work on the triggers that would make you stop before jumping to the answer. Building the right personal and organizational disciplines for you and your team is the first step, as these disciplines will cause you to stop and ask the proper questions. 

Working agreement is my favorite way of setting discipline that helps all individuals in an organization.  Think of the example above, imagine if the engineer has a simple line in the team working agreement “We will commit to dates when work is sized and prioritized”.  The engineer will need to figure out the size and priority of the work before answering the question.

At the end of the day, an answer must be given, a commitment must be made and having the right answer is what we are after.  Let’s enable and empower our engineers to help rephrase the question so they make sense to them.