Communicating with Developers

Good communication between business/product teams and engineering teams is rare. Business people think engineers are slow and inflexible. Engineers think business people are unrealistic and keep changing their minds. In reality, both sides are trying to build something good—they just speak different languages. Bridge that gap and everything moves faster.

The Communication Gap

The gap exists because business and engineering optimize for different things. Business wants features, speed, flexibility—react to market opportunities. Engineering wants stability, maintainability, quality—build for the long term. Neither is wrong, but they create tension.

Business person: "We need this feature in 2 weeks."

Engineer: "That's not enough time. We'd have to cut corners."

Business person: "I don't care about corners. Cut them."

Engineer: "Then the code will be unmaintainable and we'll pay for it later."

Both are right. The solution isn't for one side to win—it's to understand each other's constraints and trade-offs.

Outcomes vs Solutions

The single biggest improvement to developer communication is this: describe outcomes, not solutions.

When you describe the outcome (users need to reset passwords), engineers can suggest the best way to solve it. Maybe a simple email-based reset is better than a complex form. Maybe they know of a library that solves it faster. Or maybe there's a constraint you didn't mention that changes the approach.

When you prescribe the solution, you take away their expertise. You also own the consequences if your solution is wrong.

Understanding Estimates

One of the biggest sources of friction is estimation. Business wants a number. Engineers are uncertain. Compromise: estimates are ranges and assumptions matter.

Engineer: "That feature is probably 8 points, maybe 5 if it's simpler than I think, maybe 13 if there are edge cases."

Business: "So 8?"

Engineer: "Maybe. Ask me in 3 days when I've looked at the code more."

This frustrates business people. They want a number they can commit to. But estimates are inherently uncertain, especially early in a project. The best approach:

• Use story points, not hours. This accepts that the estimate is fuzzy. You can't say "15 hours" with confidence, but you can say "this is 5 points, similar to that other feature."
• Ask for assumptions. "What are you assuming about this feature?" Often, a feature is small if you assume X but large if you assume Y. Clarify assumptions.
• Track velocity. After 3 sprints, you know how many points the team delivers per sprint. You can forecast: 200 points of work, 25 points per sprint = 8 sprints. That's reliable.
• Disagree with estimates, but don't override them. If business thinks something is smaller than engineers estimated, discuss it. But don't say "we're doing it in 5 points anyway." That's not an estimate, it's a demand.

Why Estimates Are Uncertain

Engineers aren't being difficult when they say "I don't know exactly how long that will take." They're being honest. Here's why estimates are hard:

• Discovery takes time. They don't know what they'll find until they dig into the code. "Oh, the API doesn't support that. We need to extend it first. That's 3 extra days."
• Dependencies are unknown. Is the database schema ready? Is the API from the vendor finished? Are there breaking changes in recent library updates?
• Complexity is hidden. A feature looks simple on the surface but has edge cases. "Handle refunds" sounds simple until you realize it needs to handle 10 different scenarios.
• Technology changes. A library might have a bug. A new version might break compatibility. The engineer didn't anticipate this, so the estimate was wrong.

This is why waterfall projects fail—they lock in estimates upfront, but reality is messier. Agile accepts this by using small increments. You estimate the next 2 weeks, not the next 2 years.

Prioritization When Everything Is Urgent

A common complaint from teams: "Everything is marked urgent. Nothing is prioritized." This is death by a thousand paper cuts. The team can't focus. They thrash between tasks. Nothing ships.

How to fix it:

• Define urgent. Urgent should mean "impacts revenue, security, or user experience right now." A feature that's nice to have isn't urgent.
• Allow only a few urgent items. If more than 20% of the sprint is urgent, your definition is wrong.
• Have a triage process. When something urgent comes in, pause the team and decide together. Is it really urgent? What does it push out?
• Say no. "That's important, but we're committed to these three things this sprint. It goes in the backlog for next sprint." Saying no protects the team's ability to deliver.

Asking "Why"

When a developer suggests something technical, ask why. This isn't about doubting them—it's about understanding the trade-off.

Engineer: "We should rewrite the API."

Business: "Why? It's working fine."

Engineer: "It's slow and hard to maintain."

Business: "How slow? Are users complaining?"

Engineer: "Response times are 2 seconds. We get complaints in peak hours. It takes 3 days to add a new endpoint."

Business: "So if we rewrite it, what's the improvement?"

Engineer: "Probably 200ms response times, and 1 day to add an endpoint."

Business: "How long to rewrite?"

Engineer: "2 sprints."

Now you have what you need to decide. Spend 2 sprints to gain speed and reduce feature development time by 2 days per feature? Maybe yes if you're adding features frequently. Maybe no if you're in maintenance mode.

Running Effective Meetings

Have an agenda. Meetings without agendas meander. 30 minutes becomes an hour. People zone out.

Keep engineers in the loop before the meeting. If you're presenting a design or a decision, share it with the engineering team first, async. They read it on their own time and come to the meeting ready to discuss, not hear for the first time.

End with clear decisions. "We're building feature X by sprint 5" is clear. "We might build feature X, or we might do something else" is not.

Record decisions. Send a follow-up: "We decided to use React instead of Vue because it has better TypeScript support. We're moving forward on this basis." Record is searchable. No arguments later about what was decided.

Asynchronous Communication

Not everything needs a meeting. Async communication is faster and lets engineers focus on deep work.

• Use Slack for quick questions. Don't schedule a meeting to ask "Is the API ready?"
• Use documents for decisions. Write a design doc. Share it. Give people 24 hours to comment. Then decide. Faster than a meeting with 8 people.
• Use email/messages for updates. "Here's what we shipped this week" is better async than a status meeting.
• Use meetings for discussion, not information transfer. If you're only transferring information, email is faster. Meetings are for nuance, debate, and decisions.

Managing Scope Changes

Scope always changes. The question is how you manage it. Mid-sprint changes destroy team morale.

When a new request comes in mid-sprint:

1. Don't add it to the sprint immediately. Pause and decide.
2. Ask the team: "Can we do this and keep our sprint commitment?" Usually, the answer is no.
3. If it's truly urgent, ask what gets pushed out. "We can do this, but then we skip that feature."
4. If it's not urgent, add it to the backlog for next sprint. It gets prioritized with everything else.

This is hard because business wants flexibility. But uncontrolled scope changes destroy predictability. Teams miss sprints. Quality suffers. The team gets demoralized.

Red Flags from the Engineer Side

A developer who can't explain things simply. If they can't explain why a technical decision matters, either they don't understand it well or it doesn't actually matter. Push for clarity.

A developer who treats questions as attacks. You ask "why do we need a rewrite?" and they get defensive. Good engineers welcome questions. Bad estimates hide behind defensiveness.

A developer who only talks about problems, never solutions. "The database is slow. The API is unmaintainable. Everything is broken." Where's the fix? Are they trying to get more resources? Clearer goals?

Red Flags from the Business Side

Micromanaging implementation details. "Use this library. Name variables like this. Write tests this way." You're not helping. You're just slowing things down.

Ignoring estimates and imposing deadlines. "Developers said 3 weeks, but I need it in 1 week. Make it happen." You're not inspiring. You're creating burnout and low quality.

Treating technical debt as laziness. "Refactoring is just code cleanup. We don't have time for that." That's like saying maintenance is waste. Technical debt compounds. Ignore it long enough and you can't ship anything.

The Power of a Good Product Spec

The best tool for clear communication is a good product specification. It doesn't have to be long. It should describe:

• What we're building (the outcome)
• Why we're building it (the business case)
• Who's affected (users, admins, developers)
• What success looks like (metrics or acceptance criteria)
• Constraints (timeline, budget, technical limitations)

A good spec gives engineers what they need to start building without constant back-and-forth for clarification.

Build Relationship

At the end of the day, good communication is built on relationship. If business and engineering trust each other, disagreements get resolved. If they don't, everything is a negotiation.

This means: eat lunch together, ask about each other's weekends, celebrate wins together. Show that you respect the other person's expertise and concerns. When conflicts come (and they will), you've built a foundation of goodwill.

The next section covers Technical Debt—what it is, how it accumulates, and how to manage it.