Thoughts

One of the less technical parts of technical leadership is creating the conditions that allow developers to do their best work.

In an agency, that means balancing two things that don’t naturally fit together.

The development team needs certainty. The client needs flexibility.

Somewhere in the middle, somebody has to make both possible.

That’s a significant part of how I see my job.

Don’t replace good account management

I value good account management enormously.

I don’t want to own every client conversation, and I don’t think technical leadership should become an alternative account management function. Good account managers and account directors understand the client, the politics, the commercial relationship and everything happening around the piece of work we’re delivering.

I work best alongside that.

The sweet spot for me is being present enough that the client knows and trusts me, while retaining a degree of separation from the day-to-day relationship.

I want to be someone who can explain a difficult technical decision, challenge an assumption or become a point of escalation when necessary.

That relationship becomes particularly important when I need to challenge the brief.

Briefs have a habit of containing the answer

Clients need briefs.

If you’re commissioning work, you need something you can define, estimate, budget for and sell internally.

The problem is that briefs have a habit of going beyond defining the problem and start defining the solution.

Instead of:

We need customers to be able to do this.

We get:

We need a platform with these 14 features that works like this.

It’s completely understandable.

A defined asset is easier to get a price for. It’s easier for an agency to estimate. It’s easier for someone client-side to take to a board or budget holder and say: this is what we’re buying.

But it can also cut the agency out of one of the most valuable parts of the process.

Technical direction.

By the time we receive the brief, dozens of decisions may already have been made about how a problem should be solved, sometimes before the people designing and building the thing have even seen it.

A good brief should give us a well-defined problem, not a fully formed solution.

You can’t just tear the brief up

There’s an obvious temptation here.

Challenge everything. Go back to first principles. Tell the client what they really need.

That can be completely counterproductive.

The person sitting opposite you may have spent three months getting that brief approved. They’ve had meetings, negotiated budgets, made commitments and persuaded other people that this is the thing the organisation needs.

Then the agency turns up and says:

Actually, we think you should do something else.

Technically, we might be right.

Commercially, we may have just made our client’s life considerably harder.

This is why challenging briefs is a battle won over time.

Clients need to see it

One thing I’ve learned repeatedly is that people respond much better to things they can see.

It’s difficult to imagine a digital experience from a specification. It’s difficult to understand why a seemingly small feature is technically complicated. It’s even harder to confidently abandon something you’ve already sold internally in favour of an abstract alternative.

So make things.

Prototype. Demonstrate. Get something into a browser. Show the alternative rather than spending three meetings describing it.

Every time you do that successfully, you build a little more trust.

And trust changes the relationship.

Eventually the conversation moves from:

Can you build what we’ve specified?

towards:

Here’s the problem. What do you think we should do?

That’s a much more valuable position for both the agency and the client.

Why is the easy thing difficult?

There’s a brilliant XKCD comic I’ve thought about throughout my career.

The joke is essentially that a developer is asked to build two features. One involves determining whether a photo was taken in a national park. Fine. The other asks whether the photo contains a bird.

The response is something like: I’ll need a research team and five years.

What appears difficult to a non-technical person can be trivial. What appears trivial can conceal an extraordinary amount of complexity.

AI has changed the specific example rather dramatically, but the point survives.

Software development is frequently unintuitive.

Part of technical leadership is demystifying that for clients without hiding behind technical language.

Why has this apparently tiny change affected the estimate?

Why can’t we just add this field?

Why does changing something now create three weeks of additional work when changing it two months ago would have taken an afternoon?

Those are reasonable questions.

“They just don’t understand development” isn’t a useful answer.

My job is to make it understandable.

Protect the team from the moving target

There’s another side to this relationship.

While I’m trying to give the client flexibility, I’m simultaneously trying to give the development team solidity.

Moving targets are horrible for developers.

A project can start with good architecture, clear requirements and sensible decisions, then gradually accumulate exceptions as the destination changes.

A component gets modified to accommodate something it wasn’t designed for. A data structure gets stretched because changing it properly would affect the deadline. Something temporary becomes permanent.

Scope creep turns into technical debt remarkably quickly.

It’s also a great way of destroying morale.

Developers want to do good work. Constantly changing what “done” means takes away the satisfaction of completing something. Work gets reopened. Decisions that were correct when they were made suddenly look wrong. Estimates stop making sense.

Eventually the team feels like it’s failing even though the conditions for success have simply changed around them.

Technical leadership has to provide some protection from that.

Not by telling the client “no” to everything, but by making changes deliberate.

The client isn’t the enemy

The reverse is equally important.

I want developers to understand that the client is usually trying to help us succeed too.

They’re dealing with their own stakeholders, changing priorities, budget pressure, deadlines and information that wasn’t available when the project started.

Sometimes what looks like indecision is somebody trying very hard to prevent considerably more work landing on us.

Sometimes a frustrating requirement exists because of a commercial reality we can’t see from Jira.

I want development teams to think commercially enough to understand that.

The best developers I’ve worked with derive satisfaction not just from elegant code, but from delivering. Hitting the deadline matters. Staying within budget matters. The client being happy matters.

Quality isn’t separate from those things.

The trick is achieving them without asking developers to absorb every bit of uncertainty in the project.

The middle is where I fit

So there’s a translation job happening in both directions.

To the client, I’m explaining why development can behave in seemingly illogical ways.

To the development team, I’m explaining why the client needs something that doesn’t necessarily make perfect technical sense.

To one side I’m trying to create flexibility.

To the other I’m trying to create stability.

Get that balance right and something quite nice happens.

Projects hit deadlines. Budgets survive. Technical debt stays manageable. Developers get the satisfaction of delivering work they’re proud of. Clients get something that solves their problem rather than merely satisfying their original specification.

And the next brief gets a little less prescriptive because we’ve earned the right to be involved earlier.

Sometimes the project truth is different

Of course, not every project works like this.

Sometimes something just needs to get done.

The deadline isn’t moving. The requirement isn’t negotiable. The technical solution isn’t going to be beautiful and nobody has the luxury of spending another month finding a better one.

That’s fine too.

There are projects where the truth is simply:

We need this by Friday and it will cost whatever it costs.

Once everybody acknowledges that truth, you can make surprisingly rational decisions.

The client can throw money at the problem. The agency can put more people on it, work around inefficiencies or knowingly accept technical compromises. Developers can understand that they’re solving a commercial emergency rather than establishing an architectural pattern we’ll lovingly maintain for the next decade.

Success on that project might simply mean price and deadline.

There’s nothing inherently wrong with that.

The mistake is pretending it isn’t happening.

If everyone — agency and client — leans into the same project truth, everyone has a chance of getting what they want.

But you can’t run every project like that.

Teams burn out. Quality deteriorates. Technical debt compounds. Throwing more people and money at problems stops working surprisingly quickly.

There has to be some rough with the smooth.

Win the relationship first

Ultimately, the ability to challenge a client is earned.

You earn it by delivering what you said you would deliver. By being transparent when things go wrong. By explaining complexity without using it as an excuse. By understanding that the client’s commercial problem matters just as much as our technical one.

Do that consistently and you gain influence.

The client starts bringing you problems rather than solutions.

The development team gets space to think rather than simply execute.

Account management has a stronger relationship because difficult technical conversations aren’t being hidden from the client.

And the agency gets to do better work.

That’s why I don’t see client relationships as something that sits outside technical leadership.

Winning hearts and minds is part of the job.

Because sometimes the best thing you can do for a development team is make sure the client trusts them enough to let them do their job.