My role at RomSoft involves a good deal of “translation” activities. Not from one language to another, but from engineer-speak into everyday language. I help my colleagues take what they do, in the language they use in their technical documents or within the team, and carry it to the people who use the product or decide whether to build it with us.
That means a lot of back-and-forth conversations, especially when deciding which stories are worth telling on the RomSoft blog. Our engineers write their own articles. What we do together is find the story: in brainstorming sessions and interviews, we discover the topics and angles worth exploring, and then I help with editing and proofreading.
Workgroup at RomSoft
Over the past years I’ve sat down with engineers and R&D specialists across our teams, from people testing software against real medical hardware to people building AI documentation tools for clinics. As an outsider privileged to look inside these projects, I’m always struck by the perception gaps. The details they find generic or too technical are often the ones I find most interesting.
Here’s one such exchange with our colleague Simona, who has spent years building software for medical devices. The detail also appears in her article Programming for Medical Devices Is a Whole Different Game:
– Wow, I had no idea that using open-source frameworks in most medical device software is a no go! – Well, yeah, because of the domain regulations! – Isn’t that a bummer? – Yes. But also, it’s fun, because you can write your own libraries or frameworks. |
When I tell my colleagues that these are the details that make their story more interesting and relatable, they look surprised. But, in time, they learn to recognize the patterns that make their cases more compelling and keep using them in their project stories.
Three of them come up again and again:
“It depends” is not a dodge
Ask an engineer whether a project should use AI agents, or how long a migration will take, and the first answer is almost always “it depends.” I used to hear that as avoidance.
Now I hear it as respect for the listener. The useful content is in what it depends on: the data involved, the regulatory context, the team, the risk someone is willing to carry. That is exactly what a client needs to hear before making a decision. We don’t cut corners: we keep the full, honest answer and make it accessible to the audience.
The limitation is often the most credible part
When someone explains the things that didn’t work, the edge case they’re still watching, or the reason they picked the boring option, the first instinct might be to leave those parts out.
We’ve learned to keep them. A story that admits where it stops is much easier to believe everywhere else. For clients in regulated industries, who have heard every promise the market can make, the honest limit is often what makes the rest of the story land.
When Simona told the story of how she managed the entire documentation for a full software rewrite of a Class C contrast media injector console, she included one detail that many others would dismiss as unimportant: her team couldn’t use more modern, effective communication protocols because the legacy LAN cabling between the CT room and the assistant’s control room was built into the clinic’s walls and couldn’t be replaced. It became one of the most compelling parts of her story: a real-world constraint no one could engineer away.
Confidentiality forces better storytelling
Much of our work is under NDA. We often can’t name the client, the device, or the product. At first that felt like writing with one hand tied.
It turned out to be a discipline. Without a logo to lean on, you have to find what actually matters: the problem, the constraint, the decision, and what changed because of it. Those are the parts a future partner can recognize in their own situation, and they travel without any names attached.
What they have in common
All three lessons point the same way. What seems to get in the way of a clean story often makes it a better one: conditions show what really drives a decision, limits make the rest believable, and constraints like confidentiality push us toward what actually matters. A good translation works with them, not around them.
About my work
The short version of what I do is to communicate technical work. The longer version is that, in almost every software development project, under many layers of technical documentation, there’s a human story worth uncovering – and I love doing the digging. My favorite part is asking – wait, can you explain that again? over and over, until it makes sense even to a non-engineer like me. That, and doodling all over our group photos.