Episode 3: Engineer Communication Skills: Why Knowing Isn't Enough

Jona Obrador • May 5, 2026

Most project failures don’t start with bad code. They start with silence—assumptions left unchallenged, risks spotted but never raised, decisions made without context. Strong engineer communication skills are what separate teams that catch problems early from those that discover them too late.



In this series, we’ve covered how tickets rarely tell the full story and how estimation is really about surfacing risk. This post covers what ties both together: communication. Because understanding requirements and spotting risks only matters if you actually say something.

Where Projects Actually Go Wrong

Isometric blue maze with a magnifying glass, flags, and small cards on a white background

Most project issues don’t come from wrong code. They come from things that were assumed, never clarified, or simply not said out loud. These are the kinds of statements teams hear after the fact:

•    “Oh, I thought this was only for one subsidiary.”

•    “I didn’t know this runs on every save.”

•    “I assumed volume would be small.”



Nobody was wrong. But nobody made the invisible visible either. That’s the gap that engineer communication skills are meant to close.

Most project issues don’t come from wrong code. They come from things that were assumed, never clarified, or simply not said out loud. These are the kinds of statements teams hear after the fact:

  • “Oh, I thought this was only for one subsidiary.”
  • “I didn’t know this runs on every save.”
  • “I assumed volume would be small.”
Isometric blue maze with a magnifying glass, flags, and small cards on a white background

Nobody was wrong. But nobody made the invisible visible either. That’s the gap that engineer communication skills are meant to close.

1. Raise Risks Early—Even When You’re Not Sure

Futuristic isometric server with glowing purple beacon, floating UI panels, and small data icons on a white background

The instinct is to wait until you’re certain before flagging something. But by then, it’s often too late to course-correct without cost. Engineering communication isn’t about having all the answers—it’s about surfacing signals so the team can decide together.


Instead of: “Okay, I’ll implement this.”


Try: “This looks straightforward, but I’m worried about governance if this runs on every transaction.”

A ticket comes in: "Add validation before saving the record."


It feels like half a day of work. Then:

  • The validation turns out to depend on another record
  • That record isn't always available at the time of execution
  • A fallback is needed — but the fallback hits governance limits
  • The entire approach needs to be reconsidered

You’re not blocking progress. You’re giving the team the context they need to make a better call.

2. Say the Trade-offs Out Loud

A lot of engineers make decisions silently—pick an approach, implement it, move on. But every technical decision carries a cost, and when that cost isn’t shared, the team loses visibility into why the codebase looks the way it does.


For example: “We can handle this in a User Event for faster turnaround, but it will couple logic to transactions. If this grows, we may need to move it to a scheduled or Map/Reduce script down the line.”

A lot of engineers make decisions silently—pick an approach, implement it, move on. But every technical decision carries a cost, and when that cost isn’t shared, the team loses visibility into why the codebase looks the way it does.


For example: “We can handle this in a User Event for faster turnaround, but it will couple logic to transactions. If this grows, we may need to move it to a scheduled or Map/Reduce script down the line.”

That one statement does three things:

  • The team understands the current direction
  • Future engineers understand why decisions were made
  • Refactoring later doesn’t feel arbitrary
Isometric exchange illustration with two glowing platforms, arrows, gears, and floating app icons in purple and teal

That one statement does three things:

  • The team understands the current direction
  • Future engineers understand why decisions were made
  • Refactoring later doesn’t feel arbitrary

3. Don’t Go Quiet When Things Are Unclear

Abstract 3D illustration of a smartphone with chat, Wi‑Fi, and notification icons in blue and purple
Abstract 3D illustration of a smartphone with chat, Wi‑Fi, and notification icons in blue and purple

Engineers often go silent precisely when communication matters most—when requirements are messy, edge cases aren’t defined, or the “correct” answer isn’t obvious. The result is working in isolation, filling in gaps independently, and hoping the output matches expectations.


A better approach: “There are a few unclear parts here—especially around how this behaves with partial payments. Before I go too deep, can we align on expected behavior?”

A short pause like this is far less costly than a full rework. It’s one of the simplest engineer communication skills to develop, and one of the highest-leverage.

Engineers often go silent precisely when communication matters most—when requirements are messy, edge cases aren’t defined, or the “correct” answer isn’t obvious. The result is working in isolation, filling in gaps independently, and hoping the output matches expectations.


A better approach: “There are a few unclear parts here—especially around how this behaves with partial payments. Before I go too deep, can we align on expected behavior?”

A short pause like this is far less costly than a full rework. It’s one of the simplest engineer communication skills to develop, and one of the highest-leverage.

The Core Principles

Strong engineers don’t just write clean code—they make sure the right people have the right context. When you strip things down, three principles hold:

  • Risks should be visible. Catch them early, say them out loud.
  • Decisions should be explicit. The team deserves to know the trade-offs.
  • Assumptions should be discussable. Silence turns them into gaps.


Knowing is not enough. If it doesn’t get communicated, it doesn’t exist.


At ATSOURCE, we work with NetSuite development teams to build practices that make collaboration and communication part of how work gets done—not an afterthought. Let’s talk about how we can support your team.

Jona Obrador Senior Netsuite Developer

Meet the Author

Jona has over a decade of experience in SuiteCloud Development on the NetSuite platform. She specializes in implementing advanced solutions and has led teams in creating high-quality software. Jona holds multiple certifications and has been recognized with awards like the Summit Award and Quality Champion Award.

Tags

Accelerate ERP Success with Expert Solutions

Ready to put what you've learned into practice? ATSOURCE delivers both the specialized talent and comprehensive NetSuite support you need to turn strategy into results.‍Connect with our experts today and move from planning to performance.

Episode 2 promo: purple slide, “NetSuite Project Estimation: Why It’s About Risk, Not Time,” with computer illustration

Episode 2: NetSuite Project Estimation: Why It's About Risk, Not Time

By Jona Obrador • April 28, 2026
NetSuite project estimation isn't a time prediction — it's a risk assessment. Learn how strong developers surface uncertainty early and make estimates teams can actually plan around.
Purple podcast-style cover: “NetSuite Requirements: Why the Ticket Is Never the Full Story” with app icons on a podium

Episode 1: NetSuite Requirements: Why the Ticket Is Never the Full Story

By Jona Obrador • April 21, 2026
NetSuite requirements are rarely what they appear on the surface. Learn how strong developers bridge the gap between what's written and what the system actually needs.
A laptop displays code and a flowchart with floating icons for HTML, CSS, and PHP against a purple background.

Episode 0: Engineering Beyond Code: What Nobody Actually Teaches You

By Jona Obrador • April 14, 2026
Engineering beyond code means delivering with people, under constraints. Explore the skills NetSuite teams need beyond syntax — and why they matter more as systems grow.