How to Talk in Tech Language: A Guide for Non-Techies

This is one of the most common questions that early product managers seem to ask. There seems to be a gap between product and engineering teams that needs to be addressed.


Depending on organizational structure, your organization may or may not have a dedicated engineering team. Sometimes a product guy also serves as a project manager in smaller workplaces where s(he) has to handle a development team. Listen up, this is for your guys. Let’s be reasonable. The time to finish tasks cannot and should not be given by the product manager unless s(he) has low level coding skills and experience. If a development task takes 20 days, even if you put a strict timeline of 5 days on it, it’s not going to magically get executed in that time period. It will only add to work pressure, stress and missed deadlines. The execution also depends on the skill level of developers. Experienced developers might be able to complete a task in 2 days which an intermediate developer will do in 5 days. That definitely should not reflect badly on the intermediate developer and the 2 days should not be taken as a generalized benchmark. Your task is to take timelines from individual developers, maybe add your own buffer to it to be safe and plan your sprints around each individual’s capability. The veracity of those timelines is to be carefully reviewed as per standard project estimation models. By the end of it all, it will save everyone a lot of time, banter and needless back and forth.

The people – Developers and Product Managers

The product job profile entails putting yourself out there, speaking up, convincing higher ups and taking data driven decisions. Product people are sales guys before sales guys. They sell the product vision to internal stakeholders. Sales people require people skills in addition to every other capability. This puts them somewhere between the obnoxiously extroverted to pleasant ambiverts as people.

Developers are inherently introverts. They drain their energy if they keep talking to a lot of people. They are highly logical, sort of like Spock from Star Trek, to be able to write the highly logical code that logical machines have to understand. They are happy as long as they have a terminal in front of them and lots of coffee over the day.

Spock from start trek doing the live long and prosper hand sign

Generalizations, yes. But quite important when both teams interact with each other. Adlerian psychology states that all conflicts are the result of interpersonal relationships which is a natural consequence of human interaction.

A good start is to improve your personal relationship with developers. They are people, just like you. They have ambitions, hobbies, dreams, just like you. Talk to them, genuinely get to know them. You will be surprised by the similarities and might actually make new friends.

Always give your “Why”

Whenever you want to get a task done, always tell the developer ‘why’ you want it done instead of just saying ‘do this right now and update me when it’s done’. You are one team and learning to express yourself better might lead to a well needed ego death. It leads to healthy conversations, and gives the logical minds of the developers fundamental concepts to think about. They might surprise you with solutions that you might not have thought about.

Learn tech speak

Wouldn’t you want to learn German if your day is spent talking to German people? It makes it easier for both of you to interact with each other. Similarly, take some time to learn the basic concepts of programming, SDLC (Software Development Life Cycle), activity diagrams, software architectures, rest apis, server instances, databases, caching, ETL (Extract, Transform, Load) pipeline etc. With this knowledge, you can independently sort the genuine from the technical jargon throwing wise guy. Learn more, so you would be able to interact with the development team in a language that both of you understand.

Featured Image by storyset on Freepik

Leave a Reply

Your email address will not be published. Required fields are marked *