A few months ago, I didn’t even know what an Application Program Interface (API) was.
I managed the social media, website, and intranet of a local government and had never even heard of the term. Why would I have? I worked in an industry that still used fax machines and didn’t see why that was a problem.
Fast-forward to the present, where I now work as a content marketer for Cronofy, a company whose business model is based around building APIs.
Had my co-workers not taken the time to explain APIs and everything that goes with them to me, I wouldn’t have progressed as quickly as I have done in my current role, nor would I have felt as welcome on the team.
Picking things up quickly meant that I could make a difference to the company right from the start—there was no long, drawn-out learning curve as I familiarized myself with the company and its products. Not only that, but in order to write about APIs, I had to understand them first. My role wouldn’t have been possible without the help of the development team.
The bigger a company becomes, the more marketers, human resources (HR) staff, salespeople, and other non-technical staff it needs.
While it’s not impossible to find people in these areas with specific technical knowledge, only hiring people that already know the technical side of your business potentially isolates hundreds of prospective employees who may excel if given the chance.
Just because someone is familiar with the coding language you use or the kinds of applications that you create, doesn’t mean they are the best fit for your company culture or its current direction—sometimes it’s worth taking the time to train someone new to your technical field.
Employees from different backgrounds will have different approaches to challenges. The more varied a team’s backgrounds are, the more varied the approaches are to a challenge, and the faster the challenge can be solved.
Some of our clients at Cronofy are developers, but others have never worked with an API before. Our sales and development teams therefore take their time to explain how the product works and answer any questions.
Doing so helps to build a relationship and sense of trust with a potential customer, and the same applies to new colleagues. While it’s not solely the responsibility of programmers to explain programming to new team members, it makes you more approachable and therefore makes collaborating on future projects easier.
Team members who know how much work goes into programming are more likely to empathize with your challenges and suggest realistic time frames for future projects. You never know when you’ll have to work with someone from marketing or HR, so it’s worth taking the time to get to know the person when they first start—a collaborative team is a more successful team.
However, explaining the technicalities of developing without making the head of the new marketer, HR recruit, or salesperson explode isn’t always easy. Different people have different levels of knowledge, and some people will grasp concepts easier than others.
Where do you start? How do you start?
Assess Their Existing Knowledge
During the non-technical staff member’s first few days, get a feel for how much technical knowledge they have and how well they understand your product.
On their first day, it’s likely that they’ll receive an orientation to familiarize them with the company and introduce them to company policies. If possible, try to get some time during this period to talk to them.
New hires will be bombarded with information in their first few days, so if you can, write down some notes for them with keywords and common questions that they can study in their own time. If it’s appropriate, ask for this to be included in the official orientation.
Some people are embarrassed to ask questions and risk looking stupid, so make sure they know you’re happy to answer their queries, no matter how silly they may seem. A simple, “Don’t worry if you think it sounds stupid, we’ve all been there,” can be enough to put someone at ease.
Meeting up somewhere away from everyone else—such as a coffee shop or quiet meeting room—also helps to take the pressure off, as there is no risk of interruption by other colleagues or fear of being judged by them.
Use Plain English and Concrete Examples
Bill and Melinda Gates know the power of using plain English to explain complex ideas. When discussing their foundation, they use simple language so their ideas can reach a wider audience and help more people. While it’s unlikely any of us will change the world in the ways that Bill and Melinda Gates will, their point still rings true. The simpler you can explain something, the better someone outside your field of expertise will understand it.
Speaking and writing in a clear, unambiguous way without using complicated or technical terms is a lot more difficult than it sounds, especially when technical jargon is an everyday part of your vocabulary.
Switching gears in this way can be tough, so pretend you’re explaining your topic to a family member who’s unfamiliar with what you do. Having a target audience in mind—particularly someone you know well—makes it easier to come up with examples that you can use again and again.
Start by explaining what your product does; not in terms of computers, servers, or any of that, but its real-world benefits.
While you may know what an API is, your non-technical colleague probably won’t have a clue. The more technical language you throw at them, the more confused they’ll be.
When we talk about APIs to new staff members or potential customers, we don’t discuss HTTP requests or RESTful interfaces; we talk about how APIs allow services and applications to interact, and what the results of those interactions are.
For example, Cronofy allows SkyScanner to tap into multiple calendar services so customers can add appointments to their calendars that update in real-time.
Incorporate Metaphors
Once you’ve explained the basics of your concept, come up with a metaphor to really drive your point home. Or, if metaphors aren’t your thing, check out Sideways Dictionary. It has metaphors explaining various technical terms (you can even add your own).
For example, you could compare agile software development to finishing building a ship once you’re already out at sea. That’s why it’s so important to get the key elements out first—if you don’t, your ship will sink.
When I first started working in tech, one of the best ways an API was described to me was “the plumbing behind the apps.” This created an image in my mind of a reservoir or water treatment plant connecting to a home, with the reservoir or water treatment plant being the first application, the pipes being the API, and the home being the application requesting the data.
Using imagery in descriptions helps to hold an audience’s attention. When the metaphor ties in with something with which they’re already familiar, it helps to increase their understanding and make it more memorable.
Take Your Time
You may have to explain yourself more than once and in different ways, but it’s worth taking time now to explain things. The more time you spend explaining things at the start, the less time you’ll have to spend later, when you’re both busier and meeting up becomes more difficult. While it may be irritating to repeat yourself five times in the same day, it’s better than 50 times over the course of your working relationship. However, if your colleague does forget something at some point, stay patient. Getting annoyed won’t get you anywhere, but could create a frosty atmosphere in the office.
Following someone who’s learning to drive can be annoying when you’ve been driving for years, but we all had to start somewhere. Remind yourself of this if you feel you’re losing your patience, and take a few moments to think back to what you were like when you started out.
Encourage Them to ask Questions
While taking the time to answer all their questions may mean discussions take longer, not answering questions when you’re both free could lead to further confusion for your non-technical colleague.
It’s imperative for them to grasp basic concepts before they move on to more complicated ones. If they don’t understand the basics of what an API is, there’s no chance of them understanding API calls.
When someone asks in-depth questions, it’s a sign that they’re listening and interested in the discussion, so if your colleague is asking detailed questions, they’re getting a better grasp of the complicated topics.
Think about when you were at school—which classes stuck with you the most? Were they the ones where you were an active participant, or were they the ones where you had to make notes from a textbook?
Repeating phrases back to yourself is a good way to remember things, so don’t be surprised if your colleague reiterates something you’ve said then tags it with something like, “Is that right?” for reassurance.
If your colleague approaches you with more questions after your initial meeting, take this as a good sign and set up another meeting to answer their questions.
Listen to Them
Listening skills can never be overrated. The more you listen to someone, the more you’ll understand what their pain points are.
Some ways to be a good listener include:
- Giving the person your full attention—don’t do other things at the same time, as this splits your focus and you may not catch everything they say
- Not interrupting them
- Putting yourself in their shoes
- Maintaining eye contact
The only way you’ll completely understand your colleague’s pain points is by listening to them. They may understand perfectly what you see as a complex idea, but struggle with the simpler ideas you’ve explained. You don’t know unless you listen.
Once you’ve worked out where the gaps in their knowledge are, you can focus your time on filling in the gaps and not on explaining concepts they already understand.
Ask for Feedback
When you’ve finished, give your colleague a few hours or days to process things, then ask for some feedback, either in person or via email. You could give them a questionnaire to fill in if you’re looking for in-depth feedback, or if you want something more casual, have a quick check-in to see how they feel now that they’ve had time to digest things. Did they find your explanation easy to understand? Could you have simplified some of your descriptions?
After a couple of weeks, go back to them again and see if they have any further questions or there are any gaps in their knowledge with which you can help.
Whether you’re coding or conversing, there are always ways you can improve, so use the opportunity to get as much feedback as possible.
Collaborating Creates Stronger Teams
Explaining the intricacies of the technology industry to a non-programmer can be time-consuming and exhausting. However, when you invest the time at the start of your new working relationship to explain things, it creates a collaborative culture that’s critical to the future success of any business. It encourages a trusting, open atmosphere that allows for better teamwork and a better working environment.
Encouraging this kind of environment makes everyone more willing to suggest new ideas and take part in team discussions. It promotes creativity and the pushing of boundaries, making staff more productive, attracting better talent when recruiting, and helping companies to grow faster.
While someone may be unfamiliar with the programming world, that doesn’t mean they’re not an expert in their own field. Everyone has their own area of expertise, and the more a company embraces this and fosters an atmosphere of self-improvement, the more successful it will be.
When inquisitiveness and shared knowledge aren’t encouraged, staff is less likely to speak up in meetings, feel valued, or stick around.
A collaborative culture between departments ensures that staff members from non-technical backgrounds understand how much work goes into programming, and that you understand how much work goes into their roles. Building this kind of trust means they understand the limitations of what you do, how hard you work, and how much value you bring to the team.
What tips do you have for talking about tech to non-programmers?
