The Pains Of Not Over Communicating

What happens when you work at an agency with 1 client that everyone in your department is intimately familiar with and you all relatively work in sync with? Communication skills begin to break down and you won’t even notice it.


Shifting from an agency atmosphere and the mindset of working fast while only communicating absolutely crucial details had silently set me up to fail at a much larger company like Dropbox. Subconsciously I was sabotaging my work while feeling like I was accomplishing a lot. Here’s how to be aware of communication breakdowns and how to fix them.

Assume Someone Has No Context

The team I work with at Dropbox is small and works exclusively on Dropbox for Business. It has that small agency feel. It became easy to assume that if there were any questions about my code or what I was doing that someone would tap me on the shoulder and ask. It worked well in the agency context but ultimately failed here.

There were so many people I didn’t account for that would interact with my code at some point that I needed to assume this would be the first time someone would ever see it (even if it wasn’t the case). When code goes out for review, being able to summarize the purpose, goals and reason for its existence not only saves someone from having to dig up a project brief, but helps new employees learn while forcing you to self validate what you write. I forced myself to treat documentation and review summaries as a definitive how-to of what I created and how it interacts with code it touches.

Force Yourself To Self Validate

Let’s say code is adequately explained, documentation is provided, people know why it exists but you missed a critical step. That can now be caught early on versus a feature breaking production because you forgot something. It might not even be a step you forgot to implement but something that was missed in a project scope. Forcing yourself to document everything clearly and concisely allows for continual error checking on the project iself. This is very similar to Rubber Duck Debugging which is something you should always do.

Solve Problems Before They Arise

Beyond documenting code, over communicating your intentions on a project every step of the way will force you to raise red flags you weren’t even aware of. I was so used to in the prototyping stage of a project to only saying “Let me get a crude demo going and we’ll go from there, lets meet up again tomorrow?” That works well on a small team where I don’t need to deal with distractions and can focus on trying multiple solutions without judgement.

Take the same statement and apply in an instance where a solution to the problem you’re trying to solve may already exist. That is a day’s worth of work wasted. Saying “I am going to build a crude demo using vanilla Javascript with this kind of functionality” should jog someone’s memory that a similar piece of code exists to give you a better starting point. An extra sentence saves the hassle of a painful refactoring.

Show your support

Clapping shows how much you appreciated Tanner Godarzi’s story.