Why Coding Needs to be a Conversation, Not a List of Commands

The role of an engineer on a product team may not exactly involve saving the world, but the scene has some origin in reality: Engineers and other team members often have to come together creatively to solve a problem, and they each have their own language and jargon for describing solutions. As teams practice leaner and leaner development cycles, the process of defining and agreeing on requirements, challenges, and solutions needs to be an ongoing conversation, where everyone comes away with a shared understanding and a feeling that their role’s needs have been met.

So how do you start that conversation, and keep it going successfully throughout the life of a product? Here’s a roadmap to get you started.

Start by developing a common language

Do some level-setting at the beginning of the project to agree on general terminology that everyone can understand. Sometimes, this piece can even be as small as defining your individual product’s features in a way that allows you to speak clearly about your product roadmap.

Early in a recent project, when we were going over wireframes, people were throwing around a lot of terms that referred to the same thing: Was a “folder” the same as a “collection”? What differentiated an “item” from an “object?” By coming together in the product’s infancy and agreeing upon these terms, we were able to define our system architecture and have meaningful database model names that we still use.

Share your vision for the product

Build in time to ask your team members how they feel about the product, and share your vision as well. Try to think outside the smaller details of what everyone’s currently working on, and find opportunities to share thoughts and feelings about the product at large. You might be surprised to hear that an engineer is anxious because they’re worried that the latest feature build is getting way more complicated than they originally planned, or that a designer is excited because users have been clamoring for the feature you’re working on. These small, casual interactions build a sense of trust and shared knowledge about the larger vision that each functional team has for the product as a whole.

Leverage disagreement to come together

It can often feel like product managers, designers, and engineers are at odds with each other. Between wanting to meet deadlines and stakeholder needs, pushing for a joyful and user-centric interface, and working toward robust and uncomplicated code, things can get tricky. The key is to take this source of potential conflict and turn it into a shared learning opportunity. Make sure that every side is not just arguing for a solution, but actually communicating the “why” of a solution. If an engineer understands the user research and decision-making that went into a proposed feature, it will help them communicate all the possible solutions that can meet that particular user need, and then the team can prioritize and make better decisions.

Find opportunities to translate for each other

This opportunity often presents itself when you’re integrating new members onto the team. For example, new engineers with fresh eyes often want to jump in and optimize and uncomplicate things. While that can be a good thing, there may be situations where the more experienced team member needs to explain the design decisions that led to certain features being a certain way—and suddenly the engineer is empowered to speak for the UX designer because they understand the shared vision.

Once you find your conversational rhythm, you’ll find that team members begin to understand each other’s roles better. Because the designer now understands why the engineer pushed back on a certain complicated feature, and the engineer understands why users have been wanting a different feature, both roles on the team are now better equipped to advocate for each other and push toward a common goal—whether that’s defusing the bomb on the bus, or building a successful product.

Illustrations by Cassandra Fountaine