Direct Client Collaboration — What We've Learned

Three years ago we stopped using account managers and business analysts as the primary interface with clients. We put engineers directly in front of the people who needed software built. Here's what we learned.

What changed immediately

The first thing that changed was the speed of feedback. In the old model, a misunderstanding about a requirement would surface during a review meeting, two weeks after the code was written. In the direct model, it surfaces in the conversation before the code is written.

This sounds small. It isn't. The cost of fixing a misunderstood requirement scales with how far into development you are when you catch it. Catching it in conversation is essentially free. Catching it in a review is expensive.

What changed over time

The more interesting changes took months to become visible.

Engineers got better at the domain. When you talk directly to a medical records team for six months, you stop needing everything explained. You develop intuitions about what matters in that domain. You start anticipating problems before they're raised. This makes you dramatically more useful than an engineer who processes requirements at arm's length.

Clients got better at communicating with engineers. This surprised us. Direct collaboration is a two-way education. Clients who initially struggled to articulate requirements learned to frame problems in ways engineers could act on. The relationship produced better requirements over time, not just faster ones.

Trust compounded. When the person who commits to a timeline is the same person who builds it and ships it, accountability is clear. Clients know who to call when something breaks. Engineers feel the weight of what they commit to. This alignment makes both parties more careful and more honest.

What doesn't work

Direct collaboration has real failure modes.

It doesn't work when the client contact doesn't have authority. If every decision requires escalation to someone not in the room, direct collaboration degenerates into an indirect model with extra steps.

It doesn't work when the engineer isn't comfortable with ambiguity. Some engineers are excellent at execution but struggle with the open-ended problem-solving that direct collaboration demands. This is a hiring problem, not a process problem — but it's a real one.

It doesn't work for every type of project. Large, highly regulated projects with many stakeholders genuinely need coordination infrastructure. The direct model works best at the scale where one engineer can hold the full context of a problem.

What we'd do differently

We'd have done it sooner.

The intermediary model feels safer because it distributes responsibility. The PM takes the requirement risk, the engineer takes the implementation risk, and if something goes wrong there's always someone else to point at. Direct collaboration removes that buffer and requires everyone to be more capable.

That's uncomfortable. It's also the right discomfort to tolerate if you care about building software that actually helps people.