I’ve been on enough contracts now that I’ve started noticing patterns. Some good, some not so good. This is a collection of the things I check before signing, and the things I wish someone had told me about earlier.

Before you sign

There are three administrative questions that can catch you out if you don’t sort them early. The first two are about checks — whether the client needs a BPSS or DBS check done, and whether they’re going to organise it. The third is about timing. Some start dates are real, others depend on the client actually getting you a laptop and sorting your access. If their setup process is slow, your start date slides whether they realise it or not.

Red flags I’ve seen

A few things set off alarms for me now, usually because I learned about them the hard way.

One is code reviews by people who aren’t actually on the project. If the person reviewing your work isn’t going to be working alongside you, they’re reviewing from a distance and tend to miss the context that matters. Another is when project work gets routed through ServiceNow like it’s an IT support ticket. That’s not how delivery should work — it turns engineering into a helpdesk function.

I also take note of whether the team has any operational work at all. A squad that only ever builds new features and never touches what’s already running tends to build things that don’t hold together. And if the lead engineer isn’t actually working on your project, you’ve got a leadership gap whether anyone admits it or not.

What actually helps

The best onboarding I’ve had shared one thing in common: someone made a genuine effort to show me what was already going on before I was dropped into a single ticket. Getting a lay of the land across all the active projects, even briefly, stops you from accidentally duplicating work or stepping on toes.

If the client will let me, I create a Jira ticket for my own onboarding. It sounds small but it forces the team to think about what I actually need and who I need to meet. I also try to do 1-to-1s with everyone on the team, not just the people I’ll be pairing with. You learn a lot about how things actually work when you talk to the person who’s been there longest.

The thing I focus on most, though, is relationships. Performance matters, sure, but the contracts that go well are the ones where people actually want you around. That’s not about being popular — it’s about being reliable and easy to work with.

Questions I ask the client

I tend to run through these early, usually in the first week:

  • Who’s leading the engineering and are they still hands-on with the project?
  • What cloud platform are we on, and are there any gotchas I should know about?
  • Is ServiceNow in use, and if so, is it being used for actual project delivery or just as a ticketing system?
  • Once a story goes to production, does the team still touch it or is that someone else’s problem?
  • How does code review work, and who’s doing the reviewing?
  • Are there daily standups, and what do they actually achieve?

Most clients are happy to answer these. The ones that get defensive or vague are the ones I pay most attention to.