Working with Clients

Everything in How Systeric Works describes how the team builds. This page, and the two after it, describe the other half: how we work with the people we build for.

The short version: we are a partner, not a vendor. A vendor takes an order and delivers against it. A partner owns the outcome, tells the client what’s actually happening, and shapes scope through a real process instead of promising it in a hallway. The rest of this page is what that means in practice.

Partner, not vendor#

	Vendor	Partner (Systeric)
Unit of work	The ticket, the request	The outcome the client is trying to reach
Scope	Whatever was asked for	Whatever the problem actually needs
Bad news	Delayed until it can’t be avoided	Surfaced the week it becomes true
Status	Reported when asked	Visible by default
Pushback	Rare: the client is always right	Expected: we say so when a request isn’t the right fix

A vendor’s incentive is to keep the client happy in the room. A partner’s incentive is to keep the client’s business healthy after the call ends, even when that means disagreeing in the room. We take requests seriously as input, the same way How Systeric Works treats internal requests: not every request should be built, and saying so clearly is part of the job.

We own outcomes, not tickets#

The measure of a good engagement isn’t “we shipped what was asked.” It’s “the client’s problem is actually solved.” Those are usually the same thing. Sometimes they aren’t, and that gap is where the partnership either proves itself or doesn’t.

Owning the outcome means:

We stay accountable past the point of “it’s deployed.” A feature that ships but isn’t adopted, or solves the wrong slice of the problem, is not done. See Launch and Learn for how that accountability continues after code goes live.
We say when a request, taken literally, won’t get the client what they actually need, and propose the version that will.
We don’t treat a client’s first framing of a problem as final. The same discipline that applies internally in Discover (ask questions until you understand what’s actually happening, not just what was asked for) applies to client problems too.

Radical transparency#

The client sees the real state of the work. Not a filtered version, not a status report optimized to look good. If something is behind, we say it’s behind. If a risk shows up, we name it while there’s still time to do something about it.

This is the same standard the team holds internally. See Communication: risks are a gift when they’re flagged early and damage control when they surface after the fact. There’s no softer version of that standard for client-facing communication. If anything the bar is higher, because a client only sees what we choose to tell them.

In practice this shows up as: a weekly update that goes to the client with the same honesty as the internal one, a roadmap that’s visible and reflects what’s actually happening rather than what was originally planned, and no surprises at launch. The mechanics of that cadence are in Running an Engagement.

Scope is shaped by the process, not promised in a hallway#

A client conversation can surface a real problem in five minutes. It cannot produce a responsible scope, timeline, or price in five minutes. That takes the same rigor internal work goes through in Discover and Define: understanding who has the problem, sizing it honestly, and being explicit about what’s in and out.

So we don’t commit to shape in the room where the problem is first raised. What we commit to is running the process that produces an honest answer, quickly. That’s what Scoping & Proposals covers: how a client problem becomes a proposal we’d actually stand behind.

Trust is built by shipping, and by not hiding bad news#

Trust with a client compounds the same way it does inside the team: through consistent, truthful communication, not through never having a problem. See Communication: the team can handle hard news, it can’t handle not knowing.

Two things build trust faster than anything else:

Shipping. Working software, delivered on the cadence the release plan said it would be. Nothing rebuilds confidence like a client seeing the thing actually work.
Not hiding bad news. A missed milestone disclosed the week it happens, with a clear next step, costs far less trust than the same miss discovered later. Every anti-pattern in How Systeric Works (a launch notification sent after launch, a status that doesn’t reflect reality) costs double when it’s a client on the other end instead of a teammate.