Personify your tech-heavy products for team-wide understanding.
You’re a clever engineer with a fresh CS degree and a penchant for data science. You’re awesome at breaking out microservices and you live on Reddit’s r/programmerhumor. But what about the rest of your team? What you take as second nature may take your non-technical counterparts — like Product Managers, Designers, Marketing, or Sales — a bit longer to understand. However, taking the time to breakdown technical products is worth it. Your teammates need to be able to explain your product in order to increase business value, support your customers, and pitch for more funding when needed.
Clearly it’s beneficial for development efforts if the whole team understands what’s under the hood. That’s often easier said than done. Software developer Remy Porter calls the tendency for less-technical folks to zone out in tech-heavy conversations “the Technobabble effect.”
Despite your simple diagrams and system acronyms, your teammate may still look at you like you’re speaking another language. You would feel the same if they started talking “Wideband Delphi Estimation” or “Market Atomization.”
So, how can you translate the high level points of your technical solution? They don’t have to be fluent, but here is how to get them more comfortable:
Try system personification.
No, really. Give your product’s backstage elements humanistic qualities, and use human verbs to talk about workflows.
As @Remy Porter explains,
“By simply talking about software and infrastructure in human terms, our jargon ceases to be technobabble and becomes a character trait. We can discuss what our software thinks, what it wants. We can build a personality around the technical facts to communicate memorably and clearly. This is how we get others to understand and to care about technical subjects.”
Think about it like this:
Old way to explain data transfer using Delta Extracts:
- New data is input into ABC database and then passes through a specific listener, through a filter job into a message topic as an XML file.
- MNO application calls a REST API to trigger GHI application to store the data into cloud storage and writes a subsequent success message to MNO through a Pub/Sub system.
- MNO then retrieves and reformats the XML files into DEF format for future downstream use.
To which, your PM says: “Wait, what? I forgot what GHI stands for, and I’m confused about the trigger part. Those are a lot of arrows… can we go over this again?”
Try this:
- Our users enter data into their ABC portal, and then that data is filtered and trickles down through to a Topic where it sits and waits to be needed.
- When MNO needs new data, it asks GHI app to get the data from the Topic and set it up to be grabbed from the Cloud. After asking, MNO waits for the ‘ok’ to grab it.
- When the data is safely in the Cloud, GHI tells MNO that the data is ready to grab.
- MNO grabs the data from the cloud and repackages it in a way that will make sense to other systems later on.
Extra credit: if system acronyms are confusing/plentiful, try changing them to human names!
- Examples: MNO → Manny, GHI → Greg, ABC → Abby
To which your PM says: “Oh! I get it, you’re awesome!”
Personification Perks
Clearer communication about how you’re solving a product problem has many benefits. Here’s why it’s worth taking the time:
- Better internal team and stakeholder conversations: If everyone can speak the same backstage process language, more questions can be asked and answered, expectations can be clearly set, and buy-in for future work increases.
- Better communication with customers: Cookie-cutter support answers are always subpar. Reinforcing technical product knowledge with your support and sales teams can empower them to explain the state of things to existing customers and tailor their discussions.
- Risks are easier to uncover, and brainstorming becomes is a team event:
Using personification, you’ll spend less time clarifying “which piece” you’re talking about and more time having actual conversations around systems workflows. Sure, referring to a Brand Rating Database as “Brad” may seem silly at first, but the name will help product folks spend less time feeling lost in semantics and more time comfortably discussing Brad’s functionality and how “he” communicates to other systems — making it easier to troubleshoot problems for Brad when they arise.
Think of yourself as a storyteller and your team will better understand your product’s technical functionality — I guarantee it! If there’s an easy story behind it, they’ll be better able to tell the story themselves when your stakeholder swings by and you’re on a well-deserved ping-pong break.
This is the fifth part in a series, Developers at Work, exploring the changing role of developers in today’s workplace.
How to Help Non-Technical Teammates Understand Your Tech-Heavy Product was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.
