Think about this scenario.
A product owner asks for updates from two developers fixing bugs. The first developer starts rattling off about the intricacies of his bug. He describes in great detail the parts of the code that could contain the bug and various ways to fix it. The second developer gives a more straightforward response – she simply states what the problem is and a rough estimate of the level of effort to fix it.
Notice the difference?
It’s a huge mistake to remain within your coding bubble when communicating with non-technical coworkers.
Remember to take off your developer hat when necessary hipster-dev
So how do you step out of your perspective to better engage them? Avoid an awkward conversation with these seven strategies.
Developers write code. Designers craft layouts. Managers organize and lead teams. But the differences between these actions don’t automatically create communication barriers between these roles. Communication barriers are instead created by the unique perspectives that precede these actions.
These unique perspectives are formed by many factors. Natural strengths, personal preferences, and placement in the organization are just a few. Each factor will play into an individual’s distinct preference for how they want to work. Different personality types tend to gravitate towards specific roles and are an important factor too.
Learning these different perspectives is pivotal to breaking down communication barriers. As a developer, you need to take action in going beyond your codebase and learning how other coworkers think. This brings us to the next strategy.
2) Act Like an Interviewer
The best way to learn about a non-technical coworker’s perspective is to ask questions. The key is to learn what they specifically value from their perspectives.
Perhaps the product owner above just needs high-level updates. They may be more focused on the realization of a feature than it’s technical details. Or maybe you work with a manager who is highly technical. They may appreciate the granular details of what you’re coding a bit more.
Clarifying expectations is a great way to begin learning about what your other coworkers value. For example, you could ask your project’s business analyst about how they like to define acceptance criteria. Or you could ask the designer you work with about how they prefer to iterate on designs with developers. Learning about your coworkers by asking questions over time will allow you to hone in on how to best communicate with them.
There’s another part to this equation, though.
To take the steps needed to build empathy for coworkers outside of your team, you need to foster a curious mindset for yourself. Becoming genuinely interested in how the people and processes in your organization work together is the starting point.
培养好奇感 - 那才是超越编码的存在
Foster a sense of curiosity – that’ll get you beyond learning just about coding
Outside of just the code itself, there are a million different angles to analyze when it comes to the process of building software. Think about software from the context of being built at a particular time and place, by particular people and serving specific needs.
Think about a feature. Who designed it? Who developed it and how? What’s the historical context for why it was designed and built this way? What business requirements were involved?
Or, think about your manager. What management style do they have? What traits do they value in their direct reports? What’s their vision for your team? How do they prefer to communicate with other teams?
This process of investigation is similar to what’s required to dig into a legacy codebase or build a new feature. Thinking about things at different angles and from various perspectives will help with both your technical work and your communication skills. Hell, it probably helps in any aspect of life.
3) Avoid The Silly Way to Speak with Non-Technical Coworkers
Use the knowledge gained from learning about the perspectives of your coworkers. When working with your non-technical peers, speak with them and not at them. There’s a subtle difference here. The former places a sense of importance on their perspective.
To do this you must first understand what your conversation is about at a high level. Discussing the requirements for a new feature? Mulling over architectural decisions? Scrum update? Focus on the true purpose of the conversation, and try not to modify it to include your own agenda.
For example, traditional scrum meetings involve giving updates about work completed, work in progress, and impediments. Trying to solve a problem or venting at a scrum is outside the scope of its purpose. This can give the signal that you’re more concerned about yourself than your listeners.
By remembering the true purpose of the conversation, you can communicate from common ground.
4) Know Why Word Choice Matters
Software development is comprised of entire worlds of domain knowledge. It’s often challenging enough for a developer to keep up with their own specialty. It’s significantly harder to keep software development teams in sync with required knowledge. And even more difficult than that is communicating about domain knowledge with non-technical coworkers.
Having a shared vocabulary is key to communicating from common ground. Unless your stakeholder wants to know the specifics of the MongoDB implementation you’re using, it may be best to avoid bringing it up. But there will be times when you’ll have to convey technical details in some way across teams.
Cultivate a common language between yourself and non-technical coworkers
When you do discuss tech, remember to be aware that your listeners may not understand your specific domain knowledge. Reserve plenty of room in the conversation for questions. Be mindful of your listener’s reactions and ensure that you both have a mutual understanding.
Additionally, try to stay as high-level as possible. Visualize what speaking in a high-level programming language would look like compared to speaking in Assembly. Start with higher levels of abstraction, and dig deeper into specifics if necessary.
Imagine that you’re building a new feature but you discover that legacy code has to be rewired before you can start. If it inhibits a project schedule, it’ll require a technical explanation to a Product Owner or stakeholder. You could explain by describing how the legacy code constrains the new feature at a high-level. What you probably don’t want to do is give a meandering analysis of the software architecture.
By remembering to draw from shared language and knowledge, you can keep your communications brief and effective.
5) Practice Telling Your Story
Understanding your listener is half the equation in effective communication. Knowing yourself and expressing your thoughts is the other half. You’ll need an adequate amount of self-knowledge and practice sharing it to effectively extend your influence beyond your software team.
The first step is to know what your perspective actually is. To form your preferences and opinions as a software developer, you’ll need to have enough technical knowledge. Strive to become an expert in your craft. Learn new technologies and languages, read blogs, and observe open-source projects that are relevant to you.
Outside of those hard skills, learn how software development fits together with other functions like business, marketing, operations, etc. Development processes vary by organization, but it will be beneficial to understand how they impact your ability to contribute. Learn how your workplace utilizes software development for their business and come to your own conclusions about the benefits and drawbacks.
To form your unique perspective, gather enough preliminary knowledge first
Form opinions based on both your technical and organizational knowledge. As you discover information, be open to changing them. Your perspective will naturally evolve over time as you gain experience.
Having a strong sense of your own perspective will allow you to more easily express yourself. When working outside of the development team, remember to share your point of view and the value that you provide. Part of this entails “educating” others about your role as a software developer in a sense.
This is important because non-technical folks might not know the level of effort that certain tasks require in software development (i.e. we’re not just wizards). Also, the value of non-visible development work such as infrastructure changes are also not immediately evident to outside roles. Becoming a software developer that can discuss and evangelize the value of your work will greatly expand your influence.
6) Have the Guts to Do This When Necessary
Sometimes, certain functions in an organization will collide when building software. If a project is behind schedule, developers may fight for quality code while a product owner might settle for a temporary workaround. User experience designers may fight for a design system while management is concerned that there won’t be resources available to sustain one.
Whenever there is conflict, learn to speak up with your perspective as a developer when you disagree. Look for common ground as much as possible and argue from a position of mutual understanding. If you can argue for the long-term benefits of keeping high-quality code in the above example, you may be able to make a compromise.
Remember to share these opinions in the correct mediums and in the proper way. It may be easier to discuss a compromise with someone in a leadership position one-on-one, for example, instead of among those they lead. Keep in mind your tone is equally important as well. Plenty of brilliant technical opinions are tainted by a rude delivery and inappropriate timing.
When sharing your opinions and asking for a compromise, you may find that sometimes your listeners are initially unwilling to work with you. But give it time. Sometimes people just need to take a step back and reassess new information before they can integrate it. Oftentimes, planting a seed and being hopeful for the future is enough to make an impact.
7) Always Remember the Bigger Picture
In an organization building software, software development is one piece of a larger puzzle. Compromises will be made by each business function in order to work together, but the end goal should always be the same – to build software specifically suited for its users. This ultimately enables a business to thrive by increasing revenue and/or reducing expenses.
Keeping this perspective enables you to prioritize the end goal of your organization and more easily understand and compromise with other functions. It should also remind you to pick your battles carefully. Certain debates, even if in favor of the development team, may not be worth starting in certain contexts.
Take risks, but calculate them first
Each of the above tips will sharpen your soft skills as a developer collaborating with others outside of the development team. Practice these strategies consistently and you’ll be well on your way to becoming a much more versatile communicator.