How Business Leaders Should Work With Developers

Non-technical business leaders often approach working with developers the way they’d approach any other vendor relationship — hand over requirements, wait for delivery, review the result. This works reasonably well for well-understood, bounded services. Software development, especially anything beyond the simplest projects, rarely fits that model cleanly, and business leaders who treat it that way tend to be disappointed by the results, often without fully understanding why.

Software Development Is a Collaborative Process, Not a Delivery Service

The most successful software projects I’ve been part of, on either side of the relationship, treat development as an ongoing collaboration rather than a one-way handoff. Requirements are rarely fully knowable upfront — building the thing surfaces information that changes what “right” actually looks like — and a development process that assumes otherwise tends to produce a technically compliant result that still misses the actual business need.

Give Context, Not Just Instructions

A feature request stated as “add a filter to this page” gives a developer far less to work with than “customers are abandoning this page because they can’t narrow down results by their industry — we need a way for them to do that.” The second version gives the developer enough understanding of the actual problem to make good judgment calls on the dozens of small implementation decisions that a spec never fully covers. Business leaders who consistently share the “why” behind a request, not just the “what,” get meaningfully better outcomes from their development teams.

Trust the Team’s Technical Judgment, Push Back on Priorities

A healthy working relationship draws a clear line: business leaders should set priorities, define the problem, and make the tradeoff calls between speed, cost, and scope. Developers should own how the problem gets solved technically. Business leaders who override technical implementation decisions without the relevant expertise — insisting on a specific technical approach because it sounds familiar, rather than trusting the team’s judgment — tend to introduce risk without realizing it. The reverse also holds: developers shouldn’t be making unilateral calls about business priorities that aren’t theirs to make.

Understand That “Almost Done” Isn’t a Precise Statement

Software development doesn’t finish in a smooth, linear way — the last 10% of a feature (edge cases, polish, integration with the rest of the system) often takes longer than the first 90% did. This isn’t a sign of poor estimation or a team dragging its feet; it’s a structural reality of how software gets built. Business leaders who understand this ahead of time tend to plan around it more realistically than those who take “almost done” as a precise, reliable timeline signal.

Make Decisions Promptly

Development work regularly surfaces small decisions that need business input — an edge case that wasn’t specified, a tradeoff between two reasonable approaches. Slow decision turnaround on these questions is one of the most common, and most avoidable, sources of project delay, because a blocked developer waiting on an answer isn’t actually being unproductive — the project genuinely can’t move forward on that piece until the decision is made.

Invest in a Working Relationship, Not Just a Transactional One

Developers who understand the business beyond the immediate task — its priorities, its constraints, its competitive context — consistently make better judgment calls in the countless small decisions that specifications never fully cover. This kind of understanding builds over time, through an ongoing relationship, not through a single detailed requirements document. This is a big part of why continuity of the same development team or partner over multiple projects tends to produce compounding value, rather than starting from zero each time with a new team.

A Hypothetical Example

Consider a founder who hands a development team a detailed feature specification with no context about the underlying customer problem, then reviews the finished result only at the end. The delivered feature may technically match the spec while still missing the mark on the actual customer need, because the team had no way to catch a mismatch along the way, and no context to make good judgment calls where the spec was ambiguous. A founder who instead shares the underlying problem, stays available for the small decisions that come up mid-project, and reviews progress at a few points along the way — not just the end — tends to end up with a result much closer to what was actually needed, often with less total back-and-forth than the “hand it off and wait” approach.

Red Flags in a Working Relationship

A few patterns tend to predict a rough working relationship well before a project actually goes off track. Requirements delivered as a rigid, unchangeable specification with no room for questions or clarification usually signal a relationship headed toward the “technically compliant but not actually right” outcome described above. Development updates that consistently sound vague or uniformly positive, with no specifics, often mean bad news isn’t finding a safe path to the surface, which tends to make eventual problems bigger by the time they’re finally raised. And a pattern of decisions being reversed after the fact, once work has already been built against an earlier answer, usually reflects unclear ownership over who’s actually authorized to make a given call.

None of these are fatal on their own, but noticing them early — and addressing them directly rather than hoping they resolve themselves — tends to make the difference between a working relationship that improves over the course of a project and one that slowly erodes.

The Practical Takeaway

The businesses that consistently get strong results from their development work treat it as a genuine collaboration: sharing context, trusting technical judgment on implementation while owning business priorities, making decisions promptly, and investing in an ongoing working relationship rather than a purely transactional one. This is the working style I try to bring to every technology consulting and development engagement — see how to start that conversation.