Your new team builds the system that pharmacies use to check and dispense prescriptions. On your first day someone mentions controlled drugs, owings and repeat dispensing in the same sentence, and everyone nods. You nod too. By lunchtime you have a list of words you have never heard, and a strong suspicion that the code will make no sense until they do.
That suspicion is correct. When you join a team that serves an industry you do not know, the hardest part is rarely the technology. It is the work your users do every day, and the reasons behind it.
Start a glossary on your first day and keep it where the team can see it. Every unfamiliar word, a one line definition and the name of whoever explained it. Ask people to correct it. You will learn faster, and the next person to join will thank you.
Ask to watch a real user. Half a day in a pharmacy, or an hour on a call while someone works through their queue, will teach you more than a week of reading tickets. Notice what they double check, what they skip, what makes them sigh. Those are the places the software matters most.
Learn where the rules come from. In industries like health, finance or transport, many strange features exist because a law or a regulator requires them. When something looks pointlessly complicated, ask whether a rule sits behind it before you suggest simplifying it. That question alone will earn you a lot of trust.
Find the person on the team who used to do the job. Many teams like this have a former pharmacist, nurse or accountant somewhere, often in product or support. Buy them a coffee and ask what the software still gets wrong.
Read the support tickets from the last month. They show you which parts of the work are hardest, described in the users' own words.
And give yourself time. Most people need a few months before the domain stops feeling foreign. After that, you will start seeing problems the users have stopped noticing, and that is when you become really useful.
– Asael Shinder
Top comments (0)