For a long time, I took pride in my engineering skills - partly because I commited to coding every week, always watch the latest on tech, and that.. I'm using Vim (😈)

Being a software engineer in the software regime is a great perk. There's no other field (like business field) that teaches you how to design a system. By "system" I mean a network of softwares that work with each others, that is designed at concrete and such detail levels. You cannot walk away with software without a detailed design.

The computer science world has trained us to be meticulous, so that we can know exactly when and how systems of software work together (and when it doesn't) - this enables us to find where the bug is when the whole system when wrong.

..But this meticulousness came with a caveat: Because we have to zoom in all the time, it's hard for us as engineers to zoom out and communicate effectively with other people at their same level of abstraction.

"Hey, I think you need to work on your communication. Because nobody would understand a thing you've just said."

- One of my colleague told me. It cuts deeply into my pride, at that point I know my communication skills suck to the end of the world - and I need to change that immediately.

The DID method

🔑 I learned that the key problem for communication failure is that engineers tend to get to the details almost too early

🔱 I observed there's a pattern for facilitating better and more effective conversation - using DID method (Declarative - Imperative - Declarative), which I will propose here.

Inspiration

This method is inspired by two concepts of programming in computer science:

• Declarative: You program a software by describing what you want out of the software (output-driven)
• Imperative: You program a software by describing how you want the software to run (process-driven)

The method is also inspired by the Ladder of Abstraction - a concept that you can leverage to improve your communication. However, this concept is more complicated, so I will share further in later in my upcoming post.

Declarative first

Always start with Declarative mode, you will go straightforward to what you want to get out of the conservation (and not how you do to get there)

To do that, you will always start the conversation with an overview and a quick call-to-action to the subject (like asking for help).

• Do: give an overview and the goal of the conversation
• Don't: go to the details too quick

Imperative later

During talk, you will start to branch out details as but only try to give the information just-in-time the audience needs it.

At this stage, it's crucial to add context that is relevant to your colleagues. Imperative information is necessary to lay out to get the conversation progress. The goal of this stage is to get the stakeholders understand the context of the problem & start contributing to the problem solving process.

• Do: add relevant context and steps that you have tried or learned
• Don't: give a lot of unrelated and disconnected information

Then be..Declarative again when needed

Zoom out back when it starts getting into too much detail and causing confusion.

At this stage, some assumptions and call-to-action about the problem can be made the narrow down the scope of the conversation.

When to use DID?

In reality, DID method is useful when you try to start out a conversation a non-technical stakeholders and use it as stepping stone in the problem solving process - this help your colleague quickly grasp the context of the conversation and internalize the solution of how he or she could help.

Most of the time, you should be more biased towards using declarative language instead of imperative. As everyone is working on their own project and shifting their focus almost constantly, continuous context setting is a must.

When you might not use it: The DID method might be less effective when working with other technical members in the team, especially when they already know what we're working on - and context setting at this point is rather cumbersome.

Sum up

To be an effective communicator, you will need to:

• (1) Always start with declarative language when starting a conversation with non-technical stakeholders
• (2) As the conversation progress, relevant context should be to escalate the conversation towards the end-goal.
• (3) As thing get a little too narrow and confusing, consider switching back to declarative language

Remember, Be biased to use declarative language when things are confusing.

Hope you enjoy the post!

If you have any comments or ideas please leave them at the comments to let me know. Thank you!