Communicating Effectively

It’s a common problem at work where you see a problem but you’re having a hard time trying to convince people to support your attempt at fixing it. Worse still, they might not even see it as a problem (or they don’t think it’s something that warrants any attention from anyone). I’m approaching this piece mostly from an “I need my leadership / partners to understand what I do is important” perspective. But the ideology can similarly be used on other occasions like selling an idea to your peers etc. Ideally you start thinking about this as you try to get the green light to pursue your project instead of attempting to justify it after you’ve already invested your time into it with little to show for it.

This is part of a series (The Opinionated Engineer) where I share my strong opinions on engineering practices.

Whoever you’re talking to, they have their own perspective and priorities. They care about certain things. Make sure to understand that and position your proposal from their perspective. One common communication gap is where someone keeps trying to tell their leaders “how hard they / the team has been working” - which is cool and all - but your leaders likely want to know more about “what’s in it for me?”. For example, instead of telling your manager that “I put in 60 hours a week all of last month to make this happen,” it should be more like “I shipped x MAU which is x% of the team / org goal” or “I worked overtime to handle multiple unexpected surprises (have documentation for this) to ensure that we can ship / launch / test {org priority project} in a timely manner.” Changing the framing of your statement (by empathizing with your audience) makes it significantly more appealing to your target audience.

When you pitch a project proposal, you need strong reasoning on why you think it will be worth the time investment. In most cases, you’d be making the case using some sort of metrics or goal that the project is expected to improve. However, that’s not always the case. If you have a goal metric to chase but this project doesn’t directly affect that, think of how it’s affected indirectly. In my previous piece on dev tool valuation, I mentioned engineering cost being the most straightforward measurement available.

On the other hand, if there’s a larger org-priority project, think of how to align your project with it. You might need to make some small changes in the project pitch, but the idea is that you don’t have to build your case from scratch. Instead, you are just piggybacking on an established case by explaining how your project would help with the goal of completing the larger project. This sort of positioning not only helps reduce the amount of foundational work needed to make people understand the why but also ensures that your project will continue to receive attention as a side effect of now being associated with the larger project.

Prioritization changes all the time. When there’s a top-down change in priority, make sure to ask clarifying questions to understand the reasoning behind the shift. From there, you have to then recalibrate your (team’s) projects to make sure they’re still aligned with the higher-level goals. On some occasions, this could also mean that you would have to recommend priority shifts on ongoing / planned projects depending on the leadership goal change. For example, you’re in the core infrastructure team and the company decides to pivot to “everything AI”. Make sure to understand “how AI” and potentially shift your prioritization around (like adding better GPU support, direct Ollama support etc.) to fit the leadership goal change.

Management (and shareholders) love goals. They paint a picture of predictability and allow for an easy way to evaluate how you (or the team) are doing. The higher level you get (with bigger scope and projects), the goal would be closer to company-level goals. The hierarchy probably goes something like this: (company-level goal) make more money -> sell more ads -> get more users -> keep existing users returning (team-level goal) etc. You don’t have to set the goal on how to make the company more money, but you can set a goal on how to keep existing users returning which, by proxy, would have your impact cascaded up.

Admittedly, this is something even I sometimes forget or overlook when pitching a project. The key insight is that effective communication isn’t about having the best technical solution but rather, it’s about meeting people where they are and speaking their language. When you frame your ideas through your audience’s priorities and align with existing organizational momentum, you’re offering value in return of their support.