How Codifying Can Help You To Communicate Effectively
By: Ardy Dedase
Tags: Communication, Management, Leadership, Startup, Productivity

How Codifying Can Help You To Communicate Effectively

Useful but straightforward techniques that can help you communicate effectively.

Photo by You X Ventures on Unsplash.

Table of Contents

Introduction

Ways of working and other unique factors significantly impact the way communication happens within an organization. My goal here is to provide you some tools that you can use immediately as an individual without the need to change anything in your team or organization. These tools are meant to help you communicate effectively. Other solutions might include operational changes, which I will also not cover here.

Why is this important to me?

Being able to communicate effectively consistently is an essential skill of being a leader. Many times in my career, I have received constructive feedback about becoming more effective with my communication. I see myself as a constant work in progress, especially in this area. I have experienced Brook’s law over and over again in my career [1]. While at the same time, I also enjoy being a part of hyper-growth organizations.

From Brook’s law:

Communication overhead increases as the number of people increases.

What to expect in this post (and some terminologies)

To resolve communication issues, a good grasp of your workplace jargon and domain knowledge are not enough. I will highlight six different frameworks, models, or techniques that help in solving these communication issues. Frameworks, models, or practices is a mouthful, so I’m going encapsulate these into ways of “codifying” that enable effective communication. These ways of codifying have already been around for some time. We need to know how and when to utilize them.

There are many other ways to address communication problems [2]. This blog post will focus on using codifying techniques only.

I will cover in this post what I found to be effective in my experience as a sender and as a receiver.

Sender and Receiver.

For simplicity, the Sender will be referred to as someone who delivers the message in written form while the communicator is someone who has the message verbally. The Receiver is the recipient of the message. The message can be in verbal or written form.

[Back to top]

Communication at work

There are common communication issues that could be costly in any organization. Its root causes have good reasons why they are there in the first place.

Contributing factors

Transparency and open communication. These are desirable traits in a healthy organization. For the most part, however, we could end up being constantly bombarded with information. We will have the tendency to get distracted, which reduces our ability to focus on the task at hand. The Sender ends up delivering a not so well thought of the message. The Receiver will either misunderstand the message or miss the key points of the news because it’s not easy to understand.

Transparency and open communication

Global organizational structure, i.e., remote work, distributed teams, and working across multiple timezones. These are great for globally operating organizations that value flexible working environments and diversity of ideas. This limits our communication time and medium with some of our colleagues, depending on the timezone overlaps or even worse — no overlaps. There are times when our choices to deliver a message are limited to either via Slack, email, internal blog posts, or other asynchronous means. Face to face communication is also compromised, which could make building rapport or delivery of sensitive personal conversation more challenging [3].

Global organization structure mindmap.

Individual communication styles. We all have our personal communication styles depending on the situation, whether it’s verbal or written. When you read someone’s writing, especially those whom you’ve worked with for an extended period, you can almost hear them speaking in your head. Varying communication styles could sometimes cause miscommunication in diverse teams. Some folks tend to beat around the bush; others tend to be direct while others prefer to be succinct. From words, phrases, sentences, paragraphs, emails to blog posts; all of these can get lost in translation. We want to let our colleagues be themselves if we want to nurture a diverse workforce. However, there should be a balance between giving way to individual styles and aligning to the company’s values; mileage may vary, just like in many cases.

Communication styles may vary depending on individual characteristics or situations.

[Back to top]

Common situations

The factors mentioned above contribute to causing these situations below.

You tried to rally your team to achieve Goal A, but they ended up aiming for Goal B.

You gave feedback to your teammate or colleague. You both ended up in an unproductive argument, or even worse, a damaged relationship.

You are working on a project that has many stakeholders where requirements keep coming from different directions.

After your performance review meeting with your manager, you felt like you could have done a better job in appraising your contributions. Or your manager could have done a better job keeping track of your progress.

You had to make a decision that affects a broader group of people and stakeholders. Inputs and requests are coming from multiple stakeholders. You find yourself in a “too many cooks spoil the broth” situation.

You are about to write an email to your team, but you do not know where and how to start because there is a tremendous amount of information.

Do some of these situations sound familiar to you? This is where codifying can help.

[Back to top]

How codifying can help

Codifying provides structure

Codifying removes that initial barrier that a sender faces when writing an email or a document or preparing a presentation. When communicating verbally, codifying helps the communicator organize their thoughts by following a structure that they are already familiar with. The communicator will only need to find where the idea fits in the system.

Structure gives way to predictability.

Predictability makes the message easier to follow for the Receiver. If your document is divided into subsections with headings or if your email is written down into bullet points, the readers know what to expect when they skim, scan, and read thoroughly. When you are sharing an update during your meeting, pausing in between topics in addition to giving a clue of what you are covering next will make it easier for the listeners to follow.

Predictability allows clarity to take place.

Knowing what to expect in the message helps in making it more transparent. The familiarity of how the message flows will allow you to focus on the idea that is conveyed entirely.

On the other hand, imagine receiving a message that is not adequately structured hence becomes unpredictable. You will need to scan back and forth all over the document or have to pause and think about what you just heard during the meeting, which could lead to losing focus.

Clarity provides a common understanding of the message, which benefits both the Sender and the Receiver.

Now that we know how codifying can help us in communicating effectively let’s go through some examples below. I will share some examples and other similar techniques that you can research on your own.

Codifying your message

[Back to top]

RASCI Matrix (Responsible, Accountable, Supporting, Consulted, Informed)

Also called the responsibility assignment matrix.

Usage

When we write a project plan, review a design document, or conduct a product kickoff meeting, it is essential to clarify who are the people involved and what their responsibilities are.

Providing a RASCI Matrix, especially at the beginning of a project, will help everyone involved know what is expected from them.

If this is not identified early on, there is a tendency that the project will end up with overlapping or unclear responsibilities. Then the situation could become “too many cooks spoil the broth.” Other times it can be the opposite, like the “bystander effect,” where those who are supposed to be involved trust that someone else will be held responsible, so it’s best not to do anything [4].

Example

You are the engineering lead and manager of a team that owns the payment and checkout services of your organization. One of your goals this quarter is to support a new third-party payment provider. Payment and checkout services are depended upon by multiple teams within your organization. It is also under the close eye of your senior leadership and finance teams because it directly impacts revenue. There is also a third-party solutions engineering team that you will need to work closely with to go live with the integration. Understanding the roles of these stakeholders involved is critical to the success of this project, so you have decided to agree with everyone on the roles and responsibilities involved. Here is how your RASCI matrix will look like.

Responsible — You and your team (Software Engineers) are expected to complete the task, project, or epic, ensure that it is delivered on time.

Accountable — You and your Product Manager will be the main point of contact with your leadership team, other team’s engineering leads, and product managers. These are people who will be held accountable by the leadership team or project sponsor.

Supporting — Third-party solutions engineering team. They will provide input on how to complete the task and can potentially help Responsible help the job.

Consulted — Other teams that depend on the payment services in your organization. They solely provide input on how to complete the task or what to watch out for without necessarily helping to complete the job.

Informed — senior leadership and finance department. They need to be updated on the progress.

Further reading

DACI Matrix (Decision, Approver, Contributors, Informed) and other types of matrices. Useful for decision-making, which involves multiple stakeholders [5].

RASCI example is used for product engineering teams.

[Back to top]

STAR Format (Situation, Task, Action, Result)

Usage

Most of us have most likely known about STAR Format being useful in interviews. However, STAR is also helpful in preparing promotion packets, celebrating success, conducting performance reviews, or pretty much anytime you need to give examples that will serve as evidence to a message being conveyed.

From my experience as a manager and a direct report, preparing for performance reviews can sometimes take a chunk of your time more than you need to. Even if you know very well what you have contributed during the performance cycle, getting started in noting them down or sharing them with your manager can feel like a chore. Celebrating success with your team is also best delivered with specificity as to what was achieved.

Using a framework like STAR can help provide a full picture of the examples of situations that the Sender would like to share with the Receiver.

Example

Piggybacking on the same scenario in RASCI — You are the engineering lead and manager of a team that owns the payment and checkout services of your organization. Your team has now successfully achieved this quarter’s goal ahead of time, which is to integrate with a third-party payments service provider. You want to show appreciation to your team by sending an email to your team and all stakeholders to celebrate success. You’d like to ensure that you are not short-changing your team. Therefore, accurately representing what they have achieved to all the stakeholders is essential. Also, being more specific as to what the team has achieved comes across as more appreciative compared to just sending a generic “Congratulations with a Thank You” message.

Situation — The goal is to ensure that we are supporting a new third-party payment service provider by the end of Q2. Challenges the team faced include having to work with different timezones; many groups are affected by the payment service changes, multiple stakeholders, and the criticality of payment service to the business.

Task — Update the payment and checkout services software so that it supports the new payment service provider. Work closely with the third-party solution engineers to build the integration with our services.

Action — Despite the challenges faced, the team managed to coordinate with the third-party engineers early on, prepared a project plan, worked closely with the product owner to come up with the user stories, then created the subtasks needed to accomplish every sprint. The team has also conducted design reviews to spot any flaws in the design. Deployment was responsibly executed in phases with proper feature flags.

Result — The goal was completed before the end of the quarter, which gathered positive feedback from senior leadership. Revenue numbers correlated with supporting the new payment integration has started to spike up.

Further reading

SCQA Format (Situation, Complication, Question, Answer). Similar to STAR format, commonly used in storytelling through emails [6].

STAR Format.

[Back to top]

SMART Goal (Specific, Measurable, Attainable, Relevant, Time-based)

Usage

This is probably the simplest and most commonly used in the list. This could be used for any goal; an individual plan agreed between you and your manager or a product goal set with your team.

Example

You are a mid-level software engineer working for a tech startup approaching your third year. The first half of the year has been concluded; you’ve been exceeding expectations in the last two review cycles. Now is the time for you and your manager to agree on what you want to achieve in the second half of the year as part of your career growth plan. Part of your goal is to get promoted to a senior software engineer.

Here’s a simplified example of a SMART goal that you can work on with your manager:

Your goal is to get promoted to senior software engineer by the end of the year. Our engineering competency framework states that you are expected to lead and deliver a technical project successfully. The goal can be achieved by directing the technical design and implementation payment service integration project. The integration should be rolled out in production, serving at least 80% of our live traffic.

According to our roadmap and user stories, the payment service integration project is achievable within four months.

Supporting this payment service provider is part of the company’s strategy for this year.

Let’s dissect as to how this is a SMART goal:

Specific

Get promoted to senior software engineer

and

leading the technical design and implementation.

Measurable

The integration should be rolled out in production serving at least 80% of our live traffic.

Attainable

According to our roadmap and user stories, the payment service integration project is achievable within 4 months.

Relevant

Supporting this payment service provider is part of the company’s strategy for this year and engineering competency framework states that you are expected to successfully lead and deliver a technical project.

Time-based

achievable within 4 months

Further reading

CLEAR Goal (Collaborative, Limited, Emotional, Appreciable, Refinable) is another goal-setting related principle that you can use [7].

SMART Goal example mind map.

[Back to top]

SBI Feedback (Situation, Behaviour, Impact)

Usage

Depending on the situation, poorly structured feedback, no matter how well-intended they maybe can cause misunderstanding. If we are not careful, our feedback could be perceived as blame. Different people give and receive feedback in different ways. A framework like SBI allows you to focus on the situation and how it affected you when providing your feedback. This allows the feedback receiver to know what scenario you are referring to and how their behavior in that situation has impacted you.

Example

You are an engineering lead and manager overseeing a team of engineers. In one of your team meetings, you notice that a senior engineer in your team kept interrupting the product manager while sharing their plans about the possible changes to the roadmap. The behavior has made the product manager visibly uncomfortable. Though we can assume that the senior engineer has no harm intended because they could be passionate about the product, the impact of the team meeting was evident.

Concerned about your senior engineer’s behavior, you have decided to provide the following feedback:

During this week’s team meeting, when the product manager was sharing possible changes to the roadmap, you came across as if you were deliberately interrupting their presentation. Though I believe this was not the intention, this has made everyone in the room feel uncomfortable, which resulted in an unproductive team meeting.

Here’s a breakdown of how this is an SBI feedback:

Situation

During this week’s team meeting, when the product manager was sharing possible changes to the roadmap,

Behavior

you came across as if you were repeatedly interrupting their presentation.

Impact

Though I believe that this was not the intention, this has made everyone in the room feel uncomfortable which resulted in an unproductive team meeting.

You’ll notice that the feedback is tied to a specific event, which reinforces that you are more concerned about a particular situation while not insinuating that it is a permanent part of the Receiver’s identity. It also clearly indicates that you are first seeking to understand rather than accusing the Receiver that the actions were deliberate with bad intentions. The impact as a result of the behavior provides context as to what are the possible future consequences if the feedback is not taken seriously.

Further reading

SBI-BI feedback (Situation, Behaviour, Impact — Suggested Behaviour and Impact). This is the same as SBI, but you will include a suggested behavior with its favorable impact in your feedback [8].

SBI Feedback mind map.

[Back to top]

Conclusion

Codifying is not a silver bullet that will guarantee effective communication. It is a set of tools that we can pull out of our toolbox to help us communicate effectively. The codifying techniques I shared above are barely scratching the surface. These are only the top four most common techniques that I have used, among many others. I’d encourage you to check out the other methods that you might need.

[Back to top]

Check out my posts about software architecture: