💣 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

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

You don’t leave up to chance taking action. Still, you don’t take it immediately because of priorities, capacity, and so on.

You align priorities with your manager and prioritize this work.

Extra points if you do your research, pick a solution, and document everything. You leave the ticket ready to take when you have free capacity.

“To prevent flakiness in our tests, we can mock our dependencies or increase our timeouts. We already have E2E coverage with other tests. For our pipeline, we only care about releasing our code. We’ll mock our dependencies using library X”.

5) Moving the ball forward

You start making progress.

This is the biggest productivity game-changer I have for you today.

Once you get something started, others will follow. This doesn’t mean you have to finish all the work yourself. Building on top of something is easier than starting yourself.

“I created the tracking ticket and submitted the first PR adding the mocking library dependency, and mocking the first test.”

🧪 How to apply this in everyday software engineering

• Big projects → Create a high-level proposal without low-level implementation details. Prototype the proposal.

• Software changes → Submit the first PR. Create backlog tickets so others can follow after you.

• Emails and messaging → Write a message proposing a concrete approach. Don’t talk about the problem, tackle the problem

• Code reviews → Propose an alternative and provide references. Otherwise, it’s impossible to know if a question from you is because you see a better way, or if it’s a genuine question. I like conventional comments to make my intent clear in writing.

🎯 Conclusion

“We have to”. “We could”. “Maybe we can”… Stop dropping observations on a problem and focus on the closure of the problem.

I developed the motto of asking myself: “What’s the path to green here?”.

I went from rambling about details to being the one proposing actions.

It’s not like my ideas were always the final idea. But my proposals were the starting point to build on top of them. Last year I re-architected the eligibility evaluation of a frontend component, involving 3 core microservices on Amazon’s page. It started as a pain point and a proposal that I iterated later with many engineer’s feedback

👏 Weekly Applause

• How to Answer a System Design Interview Problem by

  Dev Design Digest
  . A detailed step by step guide to answer your next system design interview question.

• How Stripe Prevents Double Payment Using Idempotent API by

  System Design Newsletter
  . A quick read for the next time you want to add retries to your API calls.

• The simple secret of productive people by

  Tech Books
  . A summary of “Slow Productivity“ book, which I really liked.

• Hungry Minds by

  Alexandre Zajac
  to curate weekly news and articles to read.

🗞️ Other articles people like

😎 My strategy to become a TOP 1% engineer

💀 Grow or die: How to keep innovating in your career

🗺️ How to prepare the technical interview

🐲 How to prepare the system design interview