Thoughts on the part of technology partnerships most people never really see 

At some point in my career, I realised that the success of most technology partnerships is decided long before any code is written, any sprint starts or any architecture diagram appears. The real turning point happens in a quieter phase that rarely gets much attention: technology partnerships onboarding.

I learned this gradually. Early in my work at Spyrosoft, I kept noticing the same pattern. The projects that felt calm and collaborative months down the line always started with a period where everyone took onboarding seriously. The ones that became tense or chaotic often had tiny moments of misalignment right at the beginning that went unnoticed.

Over time, I stopped seeing the onboarding of technology partnerships as paperwork and started treating it more like the setting of a tone. A relationship is shaped heavily by its first interactions. Technology partnerships are no different.

Start with intent, not checklists

One of the most valuable habits I’ve developed is to pause before any formal process begins and ask what the technology partnerships truly needs. Not what the statement of work says, not what a template demands, but what this specific group of people needs to have a good experience working together.

I’ve been surprised by how different those answers can be from one client to another. Some want structure, others want breathing room. Some need regular check-ins; others prefer to be left alone unless an issue arises. You only uncover this by talking openly about intent at the start.

The technology partnerships process matters, but only to a point 

Yes, we use structure. It keeps things moving and gives everyone a shared reference point. But I’ve seen what happens when a process becomes a rigid machine. People start serving the workflow instead of the technology partnership.

What I’ve learned is that the process should feel like scaffolding: something that supports the work without boxing anyone in.

Documentation as memory, not bureaucracy

I used to see documentation as something you did because you had to. Now I see it as protection against misunderstandings that inevitably grow over time.

Some of the most tense moments in projects come from people remembering decisions differently. Writing things down is less about formality and more about preserving a shared memory when the project gets busy and people forget what was agreed.

Tools as a way to stay honest

I’ve worked in environments where status updates lived in people’s heads. It works until it doesn’t.

Tools like Jira aren’t magic, but they create a shared view of reality. You can’t hide confusion or delay inside a tool. You also don’t waste time chasing information that should be visible.

What matters isn’t the tool itself, but the honesty it forces.

The conversations that build the relationship of technology partnerships

If I had to pick one part of onboarding that consistently makes the biggest difference, it would be the early one-to-one conversations.

Not big kick-off calls with rehearsed talking points. Quiet conversations with the people who will genuinely shape the project.

These exchanges reveal things nobody writes down: personal expectations, communication habits, unspoken worries, internal pressures. I’ve learned more in these conversations than in any deck or document.

They’re the moments that humanise the technology partnerships.

Timelines need to respect real life

There is always the temptation to build the perfect plan. But real projects aren’t tidy. People take holidays. Approvals take longer than expected. Priorities shift.

The timelines that work are the ones that build in some grace. A plan that acknowledges reality is far more useful than one that looks impressive on paper.

Staying close after the handover

There is a moment in every project where onboarding is technically “done,” but the client still feels a bit in the dark. This is the point where disappearing is easy but costly.

I’ve found that a few small check-ins here make a huge difference. They prevent early friction from becoming early frustration. They tell the client you’re still thinking about the relationship, not just the task list.

Why I think this quiet phase matters so much 

Looking back, almost every strong long-term technology partnership I’ve been part of as a CTO had a thoughtful start. The communication habits were built early. Trust was built early. Expectations were clarified early.

Onboarding isn’t glamorous, but it’s the moment when people decide whether this is a collaboration they’re comfortable building on. It’s where the tone of the entire relationship is set.

It’s the part of the work most people never see, but I’ve learned to treat it as the foundation. Without that foundation, everything that comes later has to carry more weight than it should.