Working with Non-Technical Teams

"That's a Quick Fix, Right?"

When I heard this, I swallowed what I really wanted to say. The marketing team asked for a landing page change. In their mind, it was "change a button color." In reality: update the color token in the design system, check the blast radius, modify A/B test configuration. Estimated time: 3 hours. Not "quick."

But this isn't the marketing team's fault. They don't know code. "Button color = simple" is a totally reasonable assumption for them. Bridging that gap is my job.

The Ability to Translate Technical Jargon

"The CI/CD pipeline failed so the deployment didn't go through." Say that to the product team and you'll get blank stares. Translated: "The automated checks caught a problem, so the update hasn't gone live yet. I'll fix it within an hour."

This translation ability is the most important skill for working with non-technical teams. I call it the "explain it to my mom" test. (My mom would be offended if she read this.) Using jargon isn't showing knowledge — it's blocking communication.

Why I Multiply Estimates by 1.5

"How long will this take?" When a developer says "two days," it usually takes four. This isn't lying — developers think in pure coding time. Meetings, code review, unexpected bugs, testing, deployment — none of that makes it into the estimate.

So now I give 1.5x my actual estimate. "I think it'll take two days, but with testing and review, let's say three." Finish in two and a half, and you hear "that was fast!" Finish in three, and you kept your promise.

Once, even 1.5x wasn't enough. Said three days, took five. An external API had undocumented rate limits. Since then, anything with external dependencies gets 2x. (Still blows up sometimes.)

Share Progress Excessively

Among developers, "PR is up" is sufficient. Non-technical teams don't know what a PR is. So I share like this:

• "Currently in the design phase. I'll share the screen flow by tomorrow."
• "Coding in progress. About 60% done, you can review Thursday."
• "Built and in internal testing. Visible in production Friday."

Three stages. Since I started posting status updates twice a week on Slack, "how's it going?" messages dropped dramatically. Five minutes per update saves me seven "when's this done?" DMs.

The Art of Saying No

"That's not possible" is the worst response. Non-technical teams feel rejected, and they don't understand why. Instead:

"That approach would take two weeks, but if we adjust it this way, it's doable in three days. The result is similar — the technical constraints are just different."

Offering an alternative turns "no" into "here's how." That difference is huge. The marketing team lead used to say "dev always says no." After I started habitually offering alternatives, it became "dev gives us great options." (I heard that secondhand from another team member.)

This Is About Attitude, Not Skill

Non-technical teams don't need to understand development. But developers need to learn non-technical language. This isn't unfair — it's professional responsibility. Like a doctor shouldn't explain diagnoses in medical jargon.

Five years in, I feel communication skills mattering more than coding ability. Code you can write alone. Products you can't.