My strategy to become an actionable communicator (1 year after applying it)

Effective communication in software engineering with actionable insights from real-world experience. Learn how to transition from merely acknowledging problems to driving impactful solutions

Get the free AI Agent Building Blocks ebook when you subscribe.

---

Have you ever been clear about what to do, but people didn’t follow?

This was happening to me.

In April 2023, I received my 360 feedback and I saw a pattern.

I was arriving at a conclusion but failed to communicate it with people.

My communication was dumping details, rather than proposing actions.

I adopted a new motto for my work since then, and I’ll share it with you now.

---

In this post, you’ll learn:

1. The 5 stages of communication, from rambling to actionable

2. How to apply this to your day-to-day software engineering

3. My new motto after my 360 feedback review in 2023

---

A quick word about this

This is most effective when thinking about work that isn’t assigned directly to you.

Everyone expects you to deliver your sprint task. But let’s consider the work in a weekly on-call rotation. You are one week working on something and after that, the next person in the rotation will take over.

It’s natural to feel a lower sense of ownership if you know you’ll work on something else in a few days. It’s tempting to make your pass through the issue, drop an observation, and move on to your work next week. Zero progress made on this problem.

Multiple stages in your communication

1) Aware of the problem, but only the problem

The first step in making progress is acknowledging you have a problem. But awareness on its own doesn’t make progress to solve it.

If you are socializing effusively the problem, you are just being negative. Most people know the problems the team has, you don’t need to put them into their face

“The test are failing and blocking our pipeline intermittently.”

2) Aware of the possible solutions, but not taking action

The next step is identifying solutions for your problem.

But dropping observations about things you could do isn’t solving anything.

“The tests are failing because of the calls to dependencies in non-prod environments. We could increase the timeouts”

3) Creating a task to address the issue, but ignoring prioritization

If there’s a single truth in software engineering it’s this: There’s more work to do than capacity in the team.

You can’t take action on everything that comes to mind. So documenting is the next best alternative.

But just documenting doesn’t mean you’ll ever do it. Different people create duplicated tasks when they face the same issue

“I created a task to fix the flaky tests and added it to our big, dumpster backlog”.
(These tests will keep draining time of your team on retrying them every time they fail)

4) Creating a plan to tackle the solution