That example with the search feature felt familiar.
I've found it's one thing to explain what the system does. Explaining why it behaves that way, especially to people making product decisions, is much harder.
The what is usually the easy part: pointing at code, at metrics, at a screen. The why is where most of us, devs, struggle. Especially in the moment, with people who need to make a decision based on our answer.
During my early years on the team, it was mostly developers talking to developers. With all the technical jargon flying around, I often found myself struggling to make sense of the bugs being discussed.
That's when I realized how important storytelling is, even in engineering. It became a natural muscle to build. Being able to explain the problem, the context, and the "why" behind it saves everyone a lot of time. Otherwise, so much of the conversation is spent just getting everyone to the same level of understanding, especially when people come from different tech stacks or domains.
I think we often assume that because we're all engineers, we automatically speak the same language. But different tech stacks, domains, and levels of experience can create very different mental models. A good example is explaining a frontend problem to backend engineers (or vice versa), where the same issue can be seen through completely different lenses.
As you said, taking a moment to explain the problem, the context, and the "why" helps everyone build the same understanding before jumping into solutions. It makes discussions more productive and, in my experience, leads to better decisions as well.
Many engineers (and PMs) assume that if a technical solution is solid, it will naturally gain support. In reality, people often buy into the story of *why* it matters before they buy into the solution itself. Storytelling isn't about making ideas sound flashy—it's about making complex concepts understandable, relatable, and memorable.
A great reminder that communication is part of every product we build, not something separate from it!
I love this and I couldn't agree with it - "people often buy into the story of *why* it matters before they buy into the solution itself."
I've noticed the same thing, and I'm still learning that myself. A technically solid solution isn't always enough on its own. People first need to understand the problem it's solving, why it matters, and the trade-offs behind it before they can confidently support the solution.
Some lessons are learned the hard way. That was a good one for learning about scale and impact of load.
I agree that storytelling is important. There is usually a story behind why the logging module has an extremely difficult formatting path; transformed in the wrong place for a downstream process.
To make that understandable to the non-technical; a different skill.
I've found that knowing why something exists is often more valuable than knowing how it works. Every piece of "strange" code usually has a story behind it, and that history often explains why certain trade-offs were made. The harder part, as you said, is translating those stories for people without the technical context.
Being able to switch between those two perspectives is a skill in itself.
This is such an important skill that I’m excited you’re getting into. Engineers are pigeon holed but I’ve often found are far more creative than most people give them credit for. The work is structured, that doesn’t mean they can’t think outside of it 🙈
That aside, this is all to do with framing and stance from a linguistics perspective. We are comfortable in our speech communities, where we all use the same vocabulary and ways of explaining things. What you’re describing, to me, is an ease into another way of speaking, translating tech into business.
I agree, people think this is a soft skill but engineers translate all the time. It’s not as complicated as people make it out to be. What is gatekept is something that can be broken down with linguistic analysis.
Thank you so much for your input on this. I really appreciate it! 😊
I like the "speech communities" framing and I think is a better way of saying what I was reaching for.
It's not that translating tech into business is inherently hard. It's that most of us never practiced switching communities on purpose. We got fluent in one, and assumed that was the whole job.
What makes it hard sometimes is the pressure: a deadline, people waiting on an answer based on which they need to make a decision. Knowing the theory doesn't always make the switch easy in real time.
That example with the search feature felt familiar.
I've found it's one thing to explain what the system does. Explaining why it behaves that way, especially to people making product decisions, is much harder.
That distinction is the whole thing, isn't it?
The what is usually the easy part: pointing at code, at metrics, at a screen. The why is where most of us, devs, struggle. Especially in the moment, with people who need to make a decision based on our answer.
Appreciate you naming it that clearly 🙏.
During my early years on the team, it was mostly developers talking to developers. With all the technical jargon flying around, I often found myself struggling to make sense of the bugs being discussed.
That's when I realized how important storytelling is, even in engineering. It became a natural muscle to build. Being able to explain the problem, the context, and the "why" behind it saves everyone a lot of time. Otherwise, so much of the conversation is spent just getting everyone to the same level of understanding, especially when people come from different tech stacks or domains.
Hey Darshana 🤗,
I really like this perspective.
I think we often assume that because we're all engineers, we automatically speak the same language. But different tech stacks, domains, and levels of experience can create very different mental models. A good example is explaining a frontend problem to backend engineers (or vice versa), where the same issue can be seen through completely different lenses.
As you said, taking a moment to explain the problem, the context, and the "why" helps everyone build the same understanding before jumping into solutions. It makes discussions more productive and, in my experience, leads to better decisions as well.
Many engineers (and PMs) assume that if a technical solution is solid, it will naturally gain support. In reality, people often buy into the story of *why* it matters before they buy into the solution itself. Storytelling isn't about making ideas sound flashy—it's about making complex concepts understandable, relatable, and memorable.
A great reminder that communication is part of every product we build, not something separate from it!
Thank you so much Just J!
I love this and I couldn't agree with it - "people often buy into the story of *why* it matters before they buy into the solution itself."
I've noticed the same thing, and I'm still learning that myself. A technically solid solution isn't always enough on its own. People first need to understand the problem it's solving, why it matters, and the trade-offs behind it before they can confidently support the solution.
Some lessons are learned the hard way. That was a good one for learning about scale and impact of load.
I agree that storytelling is important. There is usually a story behind why the logging module has an extremely difficult formatting path; transformed in the wrong place for a downstream process.
To make that understandable to the non-technical; a different skill.
Hey SafeByDesign AI, welcome! 🤗
I agree with you.
I've found that knowing why something exists is often more valuable than knowing how it works. Every piece of "strange" code usually has a story behind it, and that history often explains why certain trade-offs were made. The harder part, as you said, is translating those stories for people without the technical context.
Being able to switch between those two perspectives is a skill in itself.
This is such an important skill that I’m excited you’re getting into. Engineers are pigeon holed but I’ve often found are far more creative than most people give them credit for. The work is structured, that doesn’t mean they can’t think outside of it 🙈
That aside, this is all to do with framing and stance from a linguistics perspective. We are comfortable in our speech communities, where we all use the same vocabulary and ways of explaining things. What you’re describing, to me, is an ease into another way of speaking, translating tech into business.
I agree, people think this is a soft skill but engineers translate all the time. It’s not as complicated as people make it out to be. What is gatekept is something that can be broken down with linguistic analysis.
Thank you so much for your input on this. I really appreciate it! 😊
I like the "speech communities" framing and I think is a better way of saying what I was reaching for.
It's not that translating tech into business is inherently hard. It's that most of us never practiced switching communities on purpose. We got fluent in one, and assumed that was the whole job.
What makes it hard sometimes is the pressure: a deadline, people waiting on an answer based on which they need to make a decision. Knowing the theory doesn't always make the switch easy in real time.