How we work

Two questions before any build, then the principles we hold to.

How big it is and what it will take, then who keeps it running afterwards. Those two answers decide almost everything else. What follows them is not a single recipe, because a skill and a platform are not built the same way. It is the set of things that stay true whichever of the three you are building.

The three sizes

What is the impact, and what will it take to build?

Every initiative gets sized on those two things before anything else is discussed. We use the same three words on every engagement, so a conversation about scope never turns into a conversation about vocabulary.

Sand, pebbles and rocks. It is our own shorthand, and it holds up because it sorts work by what actually decides the cost of owning it: how much has to be built, and what kind of person has to be around afterwards. Everything we do falls into one of the three, and most departments end up with a mix.

Sand

Small initiatives the team builds for itself

Contained improvements built by the people who actually do the work, with an expert beside them for guidance and nothing required from your technology team. They live inside the tools the team already has, so there is nothing new to host, licence or support, and nothing to keep alive once the session ends.

The impact of any single piece is modest. The point is that there are many of them, they compound across a department, and once the team has watched a few get built they start making their own.

An estimating department at an industrial manufacturer: a set of skills that fill the bid spreadsheet the estimators already use, built with them in workshops and deployed in waves. Read the case

Pebbles

Light systems that live somewhere and need light upkeep

Something that runs on its own, which means it has to live somewhere: a flow in your Microsoft tools, a small app on your intranet, a shared workspace, a scheduled task that keeps a dashboard current. It does need maintaining, but not by a specialist. A capable person on the business team can restart it, adjust a threshold or edit a rules table, and your technology team is involved lightly or not at all.

Built in weeks rather than months. The impact is usually a whole step of a process rather than a single task.

A technology company's leadership team: scheduled tasks that keep the weekly operating picture current, built alongside the people who run the meeting. Read the case

Rocks

New systems that need technical specialists for as long as they run

A genuinely new system: an application, a build against another system's developer tools, a digital team member owning a role across several systems and writing into them under governed rules, or a data platform with history and anonymization. Built over a few months, typically two to four, then monitored, patched and evolved for the life of the thing by people who do that professionally.

The impact is the largest of the three, and so is the commitment. That is exactly why the second question has to be answered before a rock is started rather than after. Some rocks are run once, under supervision, to clear a problem that then no longer exists.

A fashion manufacturer's inbound freight: a digital coordinator that owns the container lifecycle from supplier outreach to warehouse arrival. Read the case

The three answers

Who will run it in a year?

Put plainly: when it hiccups at seven in the morning, whose phone rings. There are only three honest answers, and picking the wrong one is the most common reason a good build quietly stops being used.

Answer one

The working team runs it alone

The people who use it every day also keep it going. This is the default for sand, because there is nothing to keep alive in the first place. It works for a pebble too, provided someone on the team is willing to be named as its owner and is shown the handful of things that can go wrong.

Answer two

Your technology team absorbs it

It joins the list of things your own technical people already maintain. The real question here is capacity rather than capability. A team that is fully committed for the year cannot absorb a rock however good it is, and agreeing otherwise in a meeting is how builds end up unowned six months later.

Answer three

Someone external runs it, such as us

It runs on our infrastructure. We operate it, monitor it and improve it as things drift, and you pay for what you use. It is the usual answer for a rock when there is no technical team with genuine room, and a perfectly good answer for a pebble when nobody in the business wants to carry it.

The answer depends on who you actually have rather than on what anyone would prefer, and we agree it together before a line is built. A company with no technical people, or three who are already booked for the year, should not be handed a rock to look after. It gets the rock run for it, or a pebble sized so that a named person in the business can comfortably keep it going.

Whichever answer you pick is written into the statement of work, so it is a decision rather than an assumption.

Size	The working team runs it	Your technology team absorbs it	Someone external runs it
Sand	DefaultBuilt with them, kept by them, nothing to host.	Rarely needed. There is nothing to support.	Not applicable: skills run in your own seats.
Pebbles	CommonWhen a named person on the team will own it.	When it touches systems your technical people already look after.	When nobody has the room, or would rather not carry it.
Rocks	Not realistic, and we will say so.	When you have technical staff with genuine capacity.	DefaultOperated by us, paid for what you use.

The method

How we build, every time.

With the people who do the work

Built in session with the person who does the job, on live files, never on a demo. The estimator prices a real bid. The coordinator opens a real file.

Measured before it is called done

Each piece is quantified on real work, and the before-and-after is measured again four weeks after deployment.

Deployed in waves, where the work allows

Not everything can be split, but most things can. Where they can, pieces go live as they complete rather than waiting for one release at the end, so the value starts arriving months earlier. Each wave ends with training for the people who use it.

Governed from the first wave

A controlled common version, personal copies people can adapt, and a route for improvements to flow back to the common version.

Packaged for a named owner

Documented and handed over to someone in your business, so the work outlives the engagement.

Nothing without an owner

No build starts without a named owner on your side who carries the expectation that it gets used.

The five questions we ask about any build

Is the work documented, and done the same way by everyone?
How much of it is rules, and how much is judgment?
How many kinds of exceptions show up?
What do the inputs look like: forms, spreadsheets and system fields, or emails, PDFs, photos and phone calls?
Does the result have to be written into a core system, or can a person confirm it in one step?

The answers decide the size, the zone it belongs in and how quickly something could realistically start. They are also the five questions worth asking yourself about anything sitting on your own list.

Three shapes

How pricing works.

Chosen alongside the answer to who runs it, up front, and written into the statement of work.

A fixed fee

For diagnostics, fluency, strategy work, office design, and builds where you want certainty about the amount before you start.

A shared-risk arrangement

For builds with a measurable baseline: a reduced rate for the build, and a large share of our fee earned on the performance actually delivered, measured on your own numbers. We offer it when we know it will work, and it asks for a named owner on your side.

Pay per use

When we run it for you: a modest set-up, then a charge for what you use, over a term. Nothing for your technology team to carry, and nothing to buy up front that you would rather not own.

We will happily walk you through numbers as soon as we understand what you are trying to do. There is nothing to sign to have that conversation, and plenty of people have it and decide to do the work themselves.

How we operate

We built the firm to already work this way.

Sterling North is not a client case study. It is a firm designed to operate the way we believe organizations will need to in five years, and it runs that way today.

AI in every seat

Every team member uses AI every day. Staffing is built around augmented output rather than headcount.

Built with the same tools

This website was built by a non-expert with AI in a few days. We ship with the tools and the habits we deploy for clients.

Learning on our own clock

Ten percent of paid hours go to learning, paid by the firm and billed to nobody, and the whole team meets every two weeks to share what worked and what broke. It is why the person in the room this month knows what changed last month.

Documentation that stays current

Every process is documented with AI tools, and the documentation changes when the process does.

Our own applications

Internal applications and templates are built around our workflows rather than adapted from generic software.

Security that runs itself

Our own controls are automated and monitored rather than written down and hoped for. Certification against ISO 27001, ISO 9001 and ISO 42001 is underway.

We are not describing a vision. We are describing how we work today. There is more on this on the firm.

Bring us a department, a list, or a program.

A thirty-minute strategy call is where the two questions get their first answers.

Book a strategy call