I have a personal theory. 95% of interpersonal problems stem from a lack of communication.
On December 11th, 1998, NASA launched the Mars Climate Orbiter (MCO). The probe was meant to orbit Mars, collect data on Martian climate and surface conditions, and, most importantly, act as a communications relay to the Mars Polar Lander.
As the MCO approached the red planet, sensors showed that the probe was going to be too far from Mars to be put into orbit. A trajectory change was planned and executed to bring the orbiter closer to the surface on September 15th. Eight days later, contact with the craft was unexpectedly lost.
The team at NASA thought that they were about 140 miles from the surface; an optimal orbital height. Later investigations showed that, in fact, the probe was only 35 miles above the surface. MCO entered the Martian atmosphere at too steep an angle and exploded.
The cause of the crash and inaccuracy of the altitude readings, were eventually found to be because of a units conversion problem. Lockheed Martin had been tasked with creating the ground-based communication software, but NASA had built the software on the orbiter itself. NASA sent readings to the ground using the SI unit for impulse, Newton-seconds. However, Lockheed interpreted those signals in their imperial counterpart, foot-pound-seconds.
This miscommunication caused the readings to show incorrectly, thus plunging the orbiter to its untimely and fiery demise.
It's worth noting that after the conclusion of the investigation, NASA did not blame Lockheed for the accident. Instead, they placed the blame on themselves, citing the lack of verification and processes that could have been used to catch the discrepancy early.
Stories like this are the reason that technical communication is so important.
As engineers, communicating with non-technical people is vitally important. It's almost never enough to be able to talk to fellow engineers about a specific algorithm, service, and data structure. At some point we're going to need to explain these concepts to someone who doesn't have a degree in Math or CS. We're going to have to translate to the business side of the office; sales, marketing, product; the jocks. In this article I want to provide tips for talking to these people in a way that is non-technical and constructive for their goals.
Let me be clear on something; the jocks are not dumb. As nerds we sometimes feel superior to anyone who doesn't understand advanced calculus or doesn't like to argue about quantum mechanics. That's a dangerous trap that's not accurate. The people running sales, marketing and the other business functions are just as smart as many of the engineers, just in a different way. A big part of getting communication right between nerds and jocks is understanding that difference. That being said, let's get started!
Tips For Talking To Jocks
Don’t Get To Detailed
Sales doesn't need to know about your merge-bubble-sort hybrid monstrosity that you're so proud of. That's not a selling point for your product. What they do need to know is that it's faster than the competition. When talking about technical details, don't get caught in the weeds of which algorithm does this or that. The jocks want to know how it affects the product. In the same way, try not to talk in data flows. Jocks don't care how the data gets from user to datastore, they care about how the user flows through screens; i.e. shoot for user stories instead of data flows when explaining things.
BUT, don't exclude edge cases. "Edge case" is a piece of engineering jargon that a lot of jocks don't understand, but is crazy important to them. The business side of the office really cares about those edge cases, they just don't know how to communicate them well, or haven't thought them through (that's what they're paying you for, genius). Edge cases are often left out of requirements, so make sure you are clear up front about what those edge cases are and how you plan to handle them. The sooner you communicate, and are clear, about edge cases, the sooner you can flesh out those details, and the less you'll have to go back to redo something because "that's not how I thought it was going to work." :facepalm:
Just like a jock wouldn't expect you to know the workings of a sales pipeline without any background, don't expect them to understand detailed technical plans. The two of you have very different backgrounds. If jocks don't understand something, take the time to explain it in laymen's terms.
For the love of all things holy do not say, “It doesn’t work like that.” That is a terrible answer. It provides no context, helps no one, and makes everyone involved angry. Instead explain WHY it doesn’t work like that. The reasoning behind why something is done the way it's done is much more important to a jock then how it's actually done. Explain the why, not the how. If they still don’t understand, don’t be afraid to utilize a whiteboard.
Relate Things Back To Business Goals
The things you're working on may seem very closed off and of minor importance to a jock. Nerds know that that is often never the case though. It's important to help them see how the things you're working on or explaining fit into the larger picture of the company. The goals you have are often small and linear, while a jocks goals are more big picture and abstract. Your job is to show them where your goals fit into that larger, abstract goal. While you see the ten steps in between here and there, they may not be able to. Help them see those in-between steps.
Try to familiarize yourself with long and short term business goals. Understanding where the company is heading will help you articulate how the small steps fit together. It's important for you to see the big picture as well.
Lastly, provide regular updates. It's not the jocks job to monitor your kanban board. Sometimes you need to be a liaison to the business side of the company. Don't get upset when they aren't up-to-date on every single thing you've been working on. Also don't go into as much detail as you might during a technical stand-up. Again, relate your work back to the big picture.
Don’t Be Afraid To Ask For Clarification
Remember that jocks have just as much jargon as you do, and they know it. Just like you wouldn't expect them to know what an API is off the top of their head, they don't expect you to know what ANR is. If you don't understand a concept or don't know an acronym ask them to explain or define it. They'll be happy to do so.
Asking questions is great until you forget what ANR means 5 minutes later. Try compiling questions into an email instead of asking in the middle of a conversation. This allows you to go back and review definitions, plus it leaves a digital trail to help you find that definition in the future.
If You See Something, Say Something
Sometimes us nerds prefer to sit back in conversation. It's not our strong point. In fact a lot of us get along better with our computer than we do any human. Unfortunately, this can't stop you from interjecting if you have something to add. People are relying on your expertise to identify what is and isn't possible, provide time constraints, and bring up edge cases. No one is going to call on you, you have to speak up.
Ever see a room full of nerds watching someone trying to get their computer hooked up to the projector? It's painful. Every nerd in the room knows exactly what is wrong and how to fix it, but no one wants to walk up and actually fix it. We have to stop doing this! When you see something that seems wrong, you have a responsibility to speak up. This applies even if you don't fully understand something. Your intuition often serves you well and you'll bring light to something others hadn't thought of.
Lastly, please, please, please bring up edge cases. You're the only one that sees them and they are crazy important. Do it!
The User Is Always Right
Jocks don't care that the data has to flow from front-end to service to API endpoint to middleware to model to database. Please don't try to explain the data flow in that way. Jocks care about the user flow, not the data flow.
When trying to explain data flow, try to translate it to user flow. Instead of saying "the user authenticates, checks for authorization, gets a token, then uses that token to look up resources," say "the user logs in and then is able to see their messages." The later makes much more sense to someone who works with potential users all day, and it's much more useful information for them. Remember that jocks usually don't care about the data flow. They don't need to! That's your job! Tailor your response to the person listening, making sure the information you give is useful and relevant to them.
Last, but certainly not least, be honest.
If you don’t understand something, ask for clarification. The big picture goals can and will have an effect on your work, so it's important to make sure you're on the right path. Being honest with yourself and others about where you are is vital.
If something is going to take you a long time, or you ran into an issue that you didn't foresee, spill the beans. Don't keep telling a PM that your ticket will be done by the end of the day for four days. Jocks understand that delays happen, if you explain that you have a plan to move forward and give an accurate estimate, no harm will come to you.
Hopefully you've come away with some pointers and guidelines to help you talk to jocks. Communication is key to any business and cross-departmental communication is very important (and often neglected). Remember that a two minute talk between Lockheed and NASA could have saved millions of dollars. Make sure your teams, jock or not, are on the same page before you launch your proverbial rocket.