I spent a lot of time yesterday arguing with someone on this website. Normally, I would call that a waste of time. But I don’t think it was in this case.

Not because I convinced the original poster they were wrong. No, they had wrapped themselves in the rhetorical cloak of the outsider iconoclast, and any criticism from a place of authority was actually proof of how right they were.

LinkedIn is fetid swamp of self-declared thought leaders, and unfortunately one of my esoteric specialist subjects (Systems Thinking) gets more than it’s fair share of misguided takes. 

These usually fall in two categories:

• The enthusiastic newcomer, having recently discovered an interesting edge of the field, mistakes it for the whole and declares it a universal tonic to all business problems.
• The cynical, lazy grifter, who uses the language and concepts of the field to wrap the usual hustle culture influencer BS in an attempt to capture eyeballs.

But occasionally you get a true believer. Someone who engaged with the ideas not to understand them, but to support a pre-existing epiphany. Concepts are cherry-picked to support their worldview, and used to armour their arguments from external criticism.

It was the third category that I encountered yesterday. My first reaction was both dismissive and derisive. My gut told me to ignore, as I would just engage emotionally and not help anyone, especially myself. But, with some reflection, I realised that there was a way to perhaps find some value. There was little hope of changing the poster’s mind, but perhaps there was a way to surface the flaw in their thinking for inspection in a way that would help others evaluate their claims better.

This meant:

• Authentically engaging with empathy for the original poster. Why had they come to this flawed conclusion?
• Not ceding my expertise, while not appealing to authority to “win” the argument.

This forced me to do something interesting. I had to engage with the core ideas of my field in the context of the post. This was fascinating. I knew the poster was wrong, but actually understanding why they were wrong reinforced my own understanding and gave me a chance to reflect on those ideas with a beginner’s mindset. I could more clearly see the seductive but flawed chain of reasoning that led to their conclusion. 

And with empathetic, thoughtful replies grounded in the core ideas of my field, I gave other readers the context to see the flaws themselves.

LLMs have made long-form posts trivial to write, with all the superficial signals of quality – language, structure and tone. Critically responding to fake expertise might just be the new signal of competence.

What do you think? Is this a valuable approach, or am I just feeding the troll a different meal?

I have 10 years’ experience on the startup side of the enterprise/vendor delivery boundary (or technical onboarding, or customer ops, or PS, whatever you want to call it) and even more than that on the enterprise side. I have horror stories you wouldn’t believe and I can’t tell you anyway. But if there was one piece of advice that I could give to startups chasing enterprise clients, it’s this:

Never start before you get paid.

Real commitment at large enterprises is only ever expressed via purchase orders. It is easy to get excited, no matter if it’s your first big logo or your 20th, when you have genuine interest from powerful allies inside a big financial institution. The CTO is on board. The business is champing at the bit. Your sales team is calculating their commission. Why not get started, show you are a team player, and wow your client with your preparedness, your alignment and your dedication to the partnership?

Because it’s not real until you get paid. The excitement from your client stakeholders may be real, their desire to execute the plan that brings you into their world may be real, but the deal is not real enough to spend your own precious time and money on. Not yet.

Firstly, you will be faster than your client at every step. You don’t need a head start.

Secondly, unlike when selling to fellow startups, and many small and midsize organisations, you are not dealing with the principals. Divisional executives, even with C-level titles, have lots of influence, but less absolute authority than you might imagine.

Thirdly, it is very unlikely that your product is the most important thing a tier 1 bank is doing this year. If it is, you don’t need my advice; you need to start your acquisition preparations.

Finally, there is a real risk that your project gets delayed, reprioritised, or pushed to another department. Your sponsor might move on, the target department might get reorganised. The CFO could wake up tomorrow and pause all discretionary spending until the board is happier. Or some other calamity could happen beyond anyone’s control between now and an actual purchase order.

So, before you start building on spec, understand the risk. And don’t do it. You don’t need to. It might impress your client champion, but if they don’t have the influence to get a PO cut before you start, they won’t have the influence to get one cut after the stormy enterprise weather arrives.

Have any horror stories you are legally able to share in the comments?

Last post I told you about “Project Boring” and I elided the details with an all too clever joke. I’d like to say I’m now going to go into those details by popular demand, but not a single person asked for this.

To recap: I had an amazing team who took a messy, slow onboarding process and started posting borderline unbelievable improvement stats. I can’t take credit for the results, but I can claim responsibility for the changes that enabled them. [link]

I started the way I always do – by annoying my new employees.

I looked over the shoulders of the technical delivery managers as they onboarded new customers. I wrote down what I thought was happening, asked many, many dumb questions, and eventually had a set of documents in my own words that all of us could agree were what was actually happening.

We repeated the same painful exercise with historical support tickets but this time we used a structured set of dumb questions. Why did a customer ask that? Where would they find the answer? What could we do so they never have to ask us again?

Once I had an understanding of the work the client had to do, from their point of view, we could start to see what was taking time, what was frustrating clients, and where we could improve.

We discovered a GitHub repository with an ancient SDK for products that no longer existed. A customer-facing Postman collection that was no longer being maintained. An out of date OpenAPI spec. Our API docs sometimes contradicted commercial contract language.

Through organisational change and drift, owners had shifted, mandates had shifted and nobody had noticed the holes opening up. These were not difficult things to fix. They just needed someone to notice.

The support tickets told us an unexpected story. Customers would go live, panic when they hit unexpected results that they thought were product bugs, but were actually integration errors. It wasn’t necessarily their fault – our product was complex and our docs were aimed at giving technical coverage of specific functions, not solution architecture.

The fix was straightforward. First, we provided guidance on integration architecture, aligned with the commercial packages we were selling. Second, we introduced go-live checklists. We wrote in a go-live review into the contract, so there was no confusion – you had to pass the check to get prod access.

This was the start of asserting control over the customer. It can be scary to demand things of a customer. But customers crave certainty, and it’s sometimes good to remember as a start up delivery team that you are the literal world experts in integrating your product. Everyone wins when that expertise is shared properly.

We were making real progress – customers had fewer surprises, the support ticket volume decreased, and we had started exercising our improvement muscles. Less chaos meant more time to improve the foundations.

Things were starting to look nice and boring.

When I joined Bud Financial as the very first Technical Delivery Director, I landed in the middle of the typical start up chaos. Bud was a Series B Fintech with an impressive roster of Enterprise names like HSBC, TSB and Transunion. I’d lived on both sides of the Enterprise/Fintech delivery relationship but never at such a small shop.

My new team had mandates, processes and a tool stack that had grown organically through several business model pivots. Not much was written down, and what was often made no sense because it was for a product or function that no longer existed. The team were absolute legends, but every engagement required heroics, and the core KPIs seemed to be locked permanently to “disappointing”.

I sat down at my shiny new laptop and created a folder called “Project Boring”.

My goal was to remove the stress and chaos from my team’s life – make sure they knew what to do without having to escalate up the chain, where to find all the things that they needed to do their jobs well, and what good looked like. I wanted to make the day-to-day work boring, so we could concentrate on more exciting things.

This is a playbook that has served me well my whole career. If your team feels like they’re drowning, lower the water level. Chaos is created by customer work, for sure, but I think it’s underappreciated how much is created by the way we handle that work. In an emergency room (or A&E depending on where you are), the chaos comes through the door non-stop, but the staff don’t add to it. In fact, certainty of method in the face of that chaos is not only how they cope, but how they deliver impossible outcomes every day.

We couldn’t control the customer (yet – that’s a story for another time), but we did have complete agency over how we did our work. We take what we do have control over and ensure that it only ever produces the results we want. This dramatically lowers the number of things that can go sideways, and turns situations from chaotic into nice and boring.

The details of what I did during “Project Boring” are unsurprisingly too boring to spend much time on. It was the stuff everyone talks about and never does.

It did however finally unstick our delivery KPIs. TTV dropped from unbearably long to sub 30 days for our API clients. Support ticket resolution time dropped by 68%. And unsurprisingly, our customers were very happy – CSAT on our onboarding process climbed to 100% and stayed there quarter after quarter. I told you they were legends.