Best practices for working together

jonsamp profile image Jon Samp ・3 min read

I've had many jobs over the past decade, including genetics researcher, admissions counselor, apple retail employee, and now I'm a software developer. Being a software developer is the best job I've had (by far), but there is a downside I rarely talk about: working with other people has become harder for me. More and more I retreat into my head, get frustrated, then I don't communicate effectively.

Like any problem, it's much easier to solve when you can define the problem and create a goal post to shoot for. Below are three problems I've noticed on every dev team I've been a part of, with best practices to address them.


Problem: Teams need feedback to improve, but it's hard to tell coworkers your opinions (for a lot of reasons).

Giving feedback to each other helps us grow together and to build the best stuff. There's a variety of feedback styles that can really help us grow together, but there are other styles that can do more harm than good. Great feedback has two traits: incredibly specific and given as quickly as possible.


Saying that a piece of work looks "really good" or feels "not quite up to our standards" is feedback that is non-specific and requires the receiver of that feedback to guess about what you really mean. Great feedback sounds like: "This piece of work has a nice, step-by-step flow with its numbered items" or "this button does not match our brand colors and caught my eye when i saw this page".


Feedback given months after the event makes it difficult to iterate and learn. In addition, the receiver of the feedback and the giver of feedback will have a growing difference of what happened and how it turned out. Giving feedback as soon as possible is important to getting value from it.


Problem: New ideas get shot down before they can grow into great ideas.

Creative thinking and new ideas are our best asset to building incredible products. It's natural to hear a new idea and to find issues with it and to think of ways it may not work, or unknown factors around things we don't know.

Instead of poking holes in ideas at the start, we can amplify them by repeating them out loud and thinking about how they could work. This is especially important at the beginning of the ideation/proposal process.

The goal is to amplify each other's ideas to better understand how they could grow. We can always find issues/unknowns later. The beginning of a product process should start with growing an idea instead of snuffing it out.

A way to do this is by repeating the person's idea back to them, and adding something of your own. Just like the "yes, and ..." improv exercise, we can encourage the people around us to propose ideas and grow them (this is in opposition to the "yes, but... " exercise, that works in the same way and instead shuts down creativity).

The "Yes" portion of the rule encourages the acceptance of the contributions added by others. Participants in an improvisation are encouraged to agree to proposition, fostering a sense of cooperation rather than shutting down the suggestion and effectively ending the line of communication. ~ Wikipedia

Positive intent

Problem: How can we know the hater on the team doesn't hate me.

When receiving feedback or when talking to others, assume positive intent. This is in an effort to avoid falling back to the human default of defensiveness. Defensiveness arises out of assuming someone's intention when they provide feedback or comments about a piece of work. By assuming an intention, we shut out critical information that can help us make progress.

By assuming that everyone has positive intent, we can diffuse defensiveness by knowing that the person speaking to us means well, even if what they are saying runs counter to our efforts.

A practical way to do this is to ask clarifying questions about the opposing point of view to make it as specific and clear as possible (instead of defending your original stance). After that, then you can make an informed decision about how to proceed. Read more from this article.


markdown guide