What you’d want to know before letting me in
Letting an outside consultant near your operating systems, your numbers and your good staff is a real decision, and a biography doesn’t help you make it. So rather than starting with where I’ve worked, here is what I think actually matters: how I make commercial judgements, how I behave around your people, how changes get proven before anything depends on them, and what’s left behind when the engagement ends.
I spent the first part of my career on the commercial side of businesses rather than in a data team, and it shows in how engagements run. The opening question is always the value at stake, never the technology, and the recommendation follows from there, which sometimes means a smaller change than anyone expected and occasionally means advising against the project altogether. A consultant who never says “this one isn’t worth doing” is selling something other than judgement, and you’d be right to wonder what.
I don’t arrive with your history, and that’s worth more than it sounds: you only get fresh eyes once. I can read the financials, the marketing, the logistics and the systems underneath them, and follow a thread from a boardroom question down to the implementation decision that answers it. Sixteen years with my longest client suggests the eyes keep finding things long after they stop being fresh.
Dataplane is founder-led and deliberately small. That caps how much we take on at once, and it’s also why the work stays coherent: the person who sits with your team, designs the system, checks the reconciliation and answers the awkward question at month three is the same person you first spoke to. Nothing gets lost in a handover because there isn’t one, and nobody more junior gets substituted in after the contract is signed.
I work beside the people closest to the operation, because they already know where the friction is and usually have well-formed opinions about it. That only succeeds if they experience the engagement as help rather than inspection, so the framing is set carefully and early: the systems have been failing them, not the reverse. In my experience the most capable people are the quickest to see the point, for the straightforward reason that it’s mostly their time being wasted.
Changes get proven before they matter. New outputs run in parallel with the old until the two reconcile, disagreements are traced to their source, and every automation goes live with monitoring built alongside it, since something will eventually misbehave and the difference between a nuisance and a disaster is how fast it’s noticed. Where a system meets a case it can’t decide confidently, it says so and passes the case to a person, and that line between machine and human judgement stays visible and movable rather than hidden in code.
The end state I’m working toward is a business that runs better without me in it. Systems documented, observable and operated by your team; reporting that people who didn’t build it can read; and, if the work has gone properly, the thing you keep is not an impressive presentation but a quieter month-end and staff doing more of what you actually hired them for. I’d rather be asked back for the next problem than for the same one.
The way in is smaller than you might expect — no workshop, no requirements document. Think of it as a truffle hunt, and me as the truffle pig. Every business has value buried where nobody has had time to dig: a report that could build itself, a number two systems quietly disagree on, an hour a day lost to re-keying. Let’s go for a walk through your business; I’ll keep my nose to the ground.
