The Rules I Try to Do Business By

Most of what I know about doing business did not arrive as a single coherent philosophy.

It came from people I worked for, people I worked alongside, things I read, mistakes I made, and stories that stayed with me long after I had forgotten where I first heard them. Some of it was learned working in businesses selling services to external customers, and some comes from running internal service provider teams in much larger businesses. All of it comes from businesses that operate profitably and in settings where I generally observe people enjoy coming to work.

Over time, I realised that the distinction between those two worlds (internal vs external customers) is smaller than it first appears.

Whether somebody is paying you directly or depending on your team from elsewhere in the same company, the job is fundamentally the same. Understand what they are trying to achieve. Make it easy for them. Do good work. Take responsibility when things go wrong. Do not make your complexity their problem.

The language tends to change inside larger companies. Customers become users, requesters, stakeholders, or business units. I think that change in language can cause a real change in behaviour.

A customer is somebody whose trust you need to earn and can lose. A user sounds like somebody who is expected to use whatever you have chosen to provide.

I think they are customers, and customers can fire you. Internally, they just do it in less obvious ways.

What follows is not a grand theory of management or a neat framework I sat down and invented. It is a collection of rules, habits, and bits of borrowed wisdom that have shaped how I try to build services, lead teams, and do business with people.

Start with the customer

Make it easy to do business with you

I’m sure you have had a situation where you want to go and buy something from some online shop and something has gone wrong, something has broken. The checkout might not work correctly, or the whole order flow might be so completely different and novel that it throws you off, or maybe they’re trying to upsell you repeatedly through the checkout process and you just give up.

I actually had one a couple of weeks ago. I wanted to buy a drone flight controller, and the only vendor in this country who has this particular thing had an e-commerce site that wanted me to phone them to activate my account, to mitigate against spam orders, before I was allowed to place an order.

So I’d go through the whole checkout process and then it got to the end, even said it had confirmed payment, and then said your order has been blocked for spam, please contact us on this phone number.

Had I had any choice to buy from any other vendor, I probably would have done, but because they were the only vendor, I actually had to phone them.

But talk about friction in your process and not making it easy to do business with you.

Any friction is bad.

That does not mean every service must be instant, free, or without controls. Some checks, approvals, and constraints exist for good reasons. It means every piece of friction should have to justify its existence.

Every form field, handoff, repeated question, and unnecessary delay places a small tax on the customer. The team responsible for a process will usually underestimate that tax because the time is being spent by somebody else.

An additional five minutes does not seem significant when you are designing a form. When thousands of people encounter that five minutes repeatedly, it becomes a meaningful organisational cost.

Friction also changes behaviour. People stop asking for help. They work around the official process, keep their own spreadsheets, or buy software on a company card. Small problems are left alone until they become serious ones because engaging with the service feels harder than living with the problem.

A service can be technically correct and still be failing because it is too difficult to use.

The customer should not need to understand your organisational structure, your queue architecture, or your internal vocabulary before they can ask for help. They should not need to know which of six teams owns their problem.

Make the front door obvious. Make the request simple. Take responsibility for moving it through the machinery behind the scenes.

Your complexity is not part of the product. A good service absorbs complexity rather than exporting it.

This applies to external service providers, but it is just as important inside a company. A colleague asking for help should not need to understand the difference between the infrastructure team, the applications team, the service desk, the security function, and the automation group.

Those distinctions may matter greatly to you. They probably do not matter at all to the person who needs something done.

Customers should be able to describe the outcome they need. It is your job to work out what happens next.

Be the customer

Do you ever think about what it’s like to use your services? No, really though, do you ever actually go and use your services yourself?

Force yourself. Get hands on with everything you provide. Experience it all. And wear the hat of the most picky customer ever.

Do not simply watch a demonstration or ask somebody to guide you through the happy path. Try to achieve a real outcome in the same way a customer would.

Raise the request through the normal front door. Use the standard account. Follow the published instructions. Wait in the same queue. Read the automated messages and experience the handoffs.

See whether you can tell what is happening, what you are expected to do next, and whether anybody has actually understood the thing you are trying to achieve.

This is some of the cheapest and most valuable customer research you can do. It costs almost nothing and can reveal problems that have survived months of service reviews, reporting, and meetings.

The problem is that senior and experienced people tend to become insulated from the ordinary experience.

They have elevated access. They know which team owns the problem. They know the undocumented workaround. They can message somebody directly, walk across the office, or quietly fix the underlying record themselves.

Every one of those privileges makes it easier for them to get something done and harder for them to understand what everybody else experiences.

The shoulder tap is particularly dangerous. You encounter a problem, message somebody you know, and it is resolved immediately. From your perspective, the organisation appears responsive and effective.

The ordinary customer does not know who to message. They submit a request, receive a generic acknowledgement, and wait. They may be passed between teams, asked for information the organisation already holds, or directed towards instructions that do not quite work. You and the customer may nominally be using the same service, but you are not having the same experience.

The more senior you become, the more deliberately you need to remove that insulation. Use a normal account. Start with the public documentation. Resist the urge to intervene at the first sign of friction.

Pay attention to the moment when you feel tempted to abandon the process and contact somebody directly. That temptation is evidence.

Leaders should mystery shop their own organisations. Product teams should use their own products. Service owners should raise their own requests. Executives should attempt the processes they mandate for everyone else.

You cannot improve an experience you have arranged never to receive.

You get exactly one chance to make a first impression

Yeah yeah, I know, it’s a cliché, but that’s because it’s true!

Dom Monkhouse once told me a story from an acquisition due diligence exercise. He had gone to visit a small business and, immediately inside the front door, was a staircase leading up into the office.

Sitting on the stairs were four copies of the Yellow Pages.

(For anyone too young to remember them, the Yellow Pages was a huge printed business directory that arrived once a year. That frequency is important.)

The first one had arrived and somebody had put it on the stairs. It remained there for an entire year, visible to every employee who walked past it each day.

The next one arrived and somebody apparently thought, yes, that seems to be where we keep the Yellow Pages, so they placed it alongside the first.

Then it happened again.

And again.

Four years of employees walking past the growing pile. Nobody threw them away. Nobody questioned why they were there. Nobody cared enough to spend ten seconds fixing it.

It would be tempting to dismiss this as an isolated thing. However, as is often the case, it was more than that. It turned out this was the visible tip of the iceberg, so to speak, and revealed a mountain of organisational apathy.

The due diligence went on to uncover a business riddled with problems that came from the same underlying behaviour. Processes had been neglected. Details had been ignored. Problems that everybody could see had become normal because nobody felt responsible for dealing with them.

The Yellow Pages did not cause the problems, obviously. But they were a giant warning light drawing immediate attention to them. And not only that, every single visitor to the office was presented with that warning light in their first impression. They also revealed where the expectation bar had been set for everybody working in that company.

Every person who walked past those directories received the same quiet message: this is acceptable here. Things can be left. Details do not matter. If everybody else has ignored it, you may ignore it too.

Every business has its own version. The problem is that you stop seeing yours.

Standards rarely collapse in one dramatic moment. They drift downwards through thousands of small permissions.

One neglected thing makes the next neglected thing feel slightly more acceptable. Eventually the organisation becomes surrounded by problems that everybody can see but nobody experiences as unusual.

The opposite is also true.

Fixing the small thing tells the people around you that noticing is worthwhile. It gives them permission to care. When somebody corrects the broken link, improves the badly worded message, or removes four years of Yellow Pages from the staircase, they drag the expectation bar upwards.

That can spread in exactly the same way as apathy. People notice what good looks like. They improve things without waiting to be told. Care becomes normal.

This is not about performative tidiness or paralysing perfectionism. There is always a point at which polishing becomes waste. It is about recognising that visible standards shape behaviour.

Give yourself permission to let small things matter. Let them pull the bar up instead of allowing neglect to drag it down.

So go and look for your own Yellow Pages moments. Walk in through your own front door, sit in your own reception, read your own automated emails, and pay attention to whatever has become part of the furniture. The things you no longer notice are the things a visitor notices first.

Then ask what they are telling people. What is your team learning about the standard you will accept, simply by watching what you walk past? What are you telling the world your tolerance allows?

Where is your bar? Not the one written into your values or your strategy deck. The one your team can see from where they are sitting.

The first interaction establishes the customer’s mental model of everything that follows. It tells them whether you are attentive, competent, organised, and interested.

A poor first impression creates a trust deficit that you may spend months correcting. A good one creates confidence and buys a certain amount of patience for the day when something inevitably goes wrong. This applies to the first sales conversation, the onboarding experience, the first screen of an application, and the first time an employee contacts an internal support team.

Customers do not experience your strategy deck. They experience moments.

Customers cannot see most of what happens inside a service provider. They cannot inspect your architecture, internal controls, project plan, or the quality of the discussions taking place behind the scenes. They make judgements from the evidence available to them, and that evidence often consists of tiny details.

A spelling mistake in an important message, an unresolved template variable in an automated email, a broken link, an error message that blames the customer, or a form that asks the same question twice can each appear trivial.

Together, they communicate care or carelessness.

Customers reasonably assume that visible sloppiness may be evidence of invisible sloppiness.

First impressions matter because the small things are often evidence of the big things. They also help determine how big those things eventually become.

Your customer can fire you

For an external service provider, the idea that a customer can leave is obvious. Inside a company, it is easier to forget.

An internal team can convince itself that it has a captive customer base. Employees are required to use the system. The process is policy. The platform is mandated and there is no visible competitor.

Customers still have choices.

They can minimise their engagement with you. They can buy around you, build around you, or hire people specifically to compensate for your weaknesses. They can create parallel processes, private spreadsheets, and shadow systems.

They can escalate until responsibility is moved elsewhere. Senior leaders can reorganise the company around you.

Sometimes being fired internally looks like losing a platform. Sometimes it looks like outsourcing. Sometimes your team continues to exist, but the rest of the organisation stops trusting it with anything important. This is why I prefer the word customer to user.

User defines somebody by their interaction with a system. Customer keeps the focus on the outcome they are trying to achieve and the quality of the service they receive.

The language changes the questions you ask. Are we solving the right problem? Was the experience good? Would they choose us again? Would they recommend us? Did we make them more successful? Those are healthier questions than asking whether a ticket technically met its service-level agreement.

An SLA can tell you that the organisation responded within four hours. It cannot tell you whether the response was useful, whether the customer had to explain the problem three times, or whether the issue passed through four teams before reaching somebody who could help. So measure the experience as well as the process.

Touchpoint measures such as transactional NPS are much better at this. You ask a question or two immediately after a real interaction, while the person still remembers what happened and can tell you which part of it was painful.

The value is in the frequency and the volume. An annual relationship survey gives you a single, heavily averaged verdict, usually months after the events that formed it and usually from the people with the strongest feelings. A touchpoint measure gives you a continuous pulse, in enough volume to see the pattern by team, by service, by request type, and over time. It tells you that something changed in March rather than telling you next January that people are unhappy.

The free-text comment is often worth more than the score. People will describe exactly where the journey hurt if you ask them while it is still fresh.

Be careful what you do with it. The moment a score becomes a target, people start managing the score rather than the experience. Treat it as a prompt to go and look, not as a stick.

Do not mistake compliance with your process for success in the eyes of the customer.

Do not make your problems the customer’s problems

I went to Center Parcs last week. Overall, amazing family holiday. But every activity required us to complete a medical form for every one of us. And we all got weighed multiple times through the week. One of the events even had an online medical form they direct you to in advance but then made you do it on paper anyway as they didn’t have a computer to go get it.

Talk about making your problems your customers’ problems! It’s not like you’re going to wildly change weight one day to the next. All of this could have been done at the first activity that needed it and then carried through them all without rework.

I can’t imagine they designed the system while thinking “you know what would be a great experience? Have them fill in a total of more than 40 forms while they are here”.

This is an obvious tell of a system not being experienced by the people responsible for overall design.

This is one of the most common failures in service design.

The organisation has fragmented systems, so the customer is asked for the same information repeatedly. A team has poor visibility, so the customer is asked to confirm something the company already knows.

Ownership is unclear, so the customer is passed from one department to another. A system cannot perform an action, so the customer is given a cumbersome set of manual instructions.

None of those things is the customer’s fault.

Asking an employee to confirm their employee number, manager, department, device type, and office location may sound harmless. If all that information already exists inside your systems, you are asking the customer to compensate for your inability to retrieve it.

The phrase “our process requires” should always make us suspicious. Sometimes the requirement is legitimate. Quite often, it is simply an old decision nobody has challenged.

Good service providers do the joining up. They reconcile the systems, find the correct owner, and carry context between teams.

That work can be difficult and expensive. It is also part of the value being provided.

Customers should not have to perform unpaid systems integration on your behalf.

This is also why user experience matters far beyond the appearance of software. User experience is the complete experience of attempting to achieve something through your service. It includes the forms, support processes, meetings, invoices, contracts, instructions, and automated messages.

Where does the customer begin? Do they understand what is being asked? Does the service behave as they expect? What happens when they make a mistake? Can they tell whether something worked, and do they know what will happen next?

Most bad experiences were not deliberately designed to be bad. They emerged because each team built its own part, optimised its own step, and assumed somebody else was responsible for the journey as a whole.

Someone must own the experience across the boundaries.

Some people have a natural instinct for user experience and others do not. That is fine, provided they know it.

If you are not good at it, partner with somebody who is and give them permission to challenge you. Involve them before the process has hardened and the system has been built.

Do not bring them in at the end to apply a coat of UX paint.

Design the system, not the symptom

Think in systems

Most business problems are products of a system rather than isolated events.

A missed target may be an individual performance problem. It may also be the predictable result of incentives, workload, unclear ownership, poor information, or a process that rewards the wrong behaviour.

Fixing the person without fixing the system often means the same problem returns with a different person attached to it.

Thinking in systems means looking beyond the immediate symptom. Ask what conditions produced the outcome, what behaviour the system encourages, and where information stops flowing.

Look for where one part has been optimised at the expense of the whole. Think about what unintended behaviour your proposed solution might create.

This matters particularly inside large organisations. Individual teams frequently make perfectly rational decisions that combine to create an irrational customer experience.

Every department protects its own capacity with another approval. Every function creates its own intake form. Every system demands its own copy of the data.

Each team meets its local target while the customer carries the accumulated weight of all that local optimisation.

The Cynefin framework is one of the most useful tools I have found for thinking about how to respond to different kinds of problems.

Do not get too hung up on labelling everything. The useful bit is that it stops you treating every problem the same way.

Some problems are clear enough that established practice, standardisation, and automation are appropriate. Some are complicated and require expertise and analysis.

Some are complex, with cause and effect becoming clear only in retrospect, so progress depends on experiments, feedback, and adaptation. Some situations are chaotic and require immediate action to create enough stability for proper understanding to begin.

A common management failure is to use the same approach everywhere.

We apply rigid processes to complex problems. We experiment where good practice is already well established. We commission lengthy analysis during a crisis that requires immediate action.

Understanding the kind of problem you are facing should come before choosing the method for solving it.

Systems thinking also requires humility. A result that looks irrational from where you are standing may make perfect sense once you understand the wider system that produced it.

Understand the load-bearing walls

Imagine somebody buying an old house and deciding to open up the ground floor.

There is a wall in the middle of a room that seems inconvenient. Nobody can explain why it is there and there is no obvious reason not to remove it.

The new owner knocks it down and discovers, rather late in the process, that it was holding up everything above it.

Businesses contain load-bearing walls too. They are the odd approval, the strangely divided responsibility, the manual check, the team boundary, or the architectural decision that no longer seems to make sense.

Somebody new takes ownership, sees an apparently irrational arrangement, and quite reasonably decides to simplify it.

Sometimes they are right. The arrangement may be outdated, badly conceived, or the result of a lazy decision made years ago. It may also be an intentional compromise that is carrying a load nobody has noticed.

Chesterton’s fence is another way of expressing the same idea. You encounter a fence across a field and cannot see why anybody put it there.

Your lack of understanding is not, by itself, a reason to remove it. It is a reason to study the fence until you understand what problem it was intended to solve.

Once you understand the purpose, you can decide whether that purpose still matters and whether the fence remains the right answer.

When teams change or responsibilities pass between people, do not begin from the assumption that those who came before you were clueless.

Respect the possibility that they were responding to information, constraints, and trade-offs that are no longer visible.

Study why the decision was made. Look for the documentation, speak to the people who were there, and examine what was happening at the time.

If you cannot find the explanation, study harder and try to reconstruct it.

The absence of documentation is not proof that there was no reasoning.

This does not mean preserving every inherited process through misplaced reverence. Organisations accumulate plenty of nonsense. It means understanding something before changing it, particularly where the consequences might travel further than the change itself.

A decision that appears inefficient may have been protecting reliability. A duplicated responsibility may have been compensating for a control weakness. A manual step may exist because an automated one previously caused damage.

The original answer may no longer be correct, but the question it was answering may still exist.

The best defence is to preserve the reasoning behind decisions while the people who made them can still remember it.

One useful method is the Y-Statement. The structure is roughly this: in the context of a particular situation, facing a particular concern, we decided to take one course of action rather than the alternatives, to achieve a desired outcome, while accepting a stated downside.

The final part matters. Real decisions usually involve a trade-off.

Recording only what was chosen makes the decision appear more obvious and absolute than it really was. Recording what you knowingly accepted helps the next person understand the circumstances under which the decision might need to change.

Write down why, not just what.

Assume that somebody else will eventually inherit your house. Label the load-bearing walls before they arrive with a sledgehammer.

Work in the open

One of the worst patterns I see in modern organisations is important work and decision-making disappearing into private Slack channels and direct messages.

If you use Slack, favour public channels. Celebrate having a high ratio of public channels to private ones, and an even higher ratio of channel conversations to direct messages.

Work conducted in private is work the organisation is likely to lose.

The immediate participants may remember the conversation, but everybody else sees only the eventual outcome. The context, alternatives, disagreement, and reasoning disappear.

Months later, somebody encounters the result and cannot understand why it exists. We have created another unexplained fence and another apparently pointless wall.

There are legitimate reasons for working privately. Personal matters, commercially sensitive discussions, security incidents, and genuinely confidential subjects need appropriate protection.

Privacy should be a deliberate control applied for a reason. It should not be the default setting for ordinary work.

My friend and former colleague Jesse Taylor once captured the question brilliantly: “What are they afraid of?” It is worth asking whenever a team habitually works behind closed doors.

What specifically would go wrong if colleagues could see this discussion?

Sometimes there is a good answer. Often there is only habit, hierarchy, or discomfort with allowing unfinished thinking to be visible.

Working in the open does not mean every employee must read everything. It means the work is available to the people who need it, including people you have not yet met.

Assume you will eventually leave the business. Assume somebody new will inherit the service, system, or decision you are working on.

Assume they will need to search for your reasoning without knowing your name, the date of the conversation, or which private group contained it.

Could they find it? Could they understand how you reached the decision, or would they find only the final artefact and be left to guess?

Closed channels and direct messages create a similar problem to the person who never takes time off. Knowledge remains concentrated around particular individuals.

The organisation appears to function while they are present, but struggles to reproduce their understanding without them.

This can happen innocently. Direct messages feel fast. Private groups feel safe. A small number of familiar people can reach decisions quickly without explaining all the context to everybody else.

The price is paid later through repeated conversations, duplicated work, and decisions that have to be rediscovered.

Work in the open. Put decisions somewhere durable and searchable. Summarise what was agreed and capture why.

Link the conversation to the resulting work and the resulting work back to the decision.

Organisational memory does not happen automatically. You have to design for it.

Use automation as a design constraint

There is familiar advice that you should never automate a broken process. It is directionally sensible, but too easily repeated.

Attempting to automate a process is often how you discover that it is broken.

Automation is intolerant of ambiguity.

A person can look at an incomplete request and infer what the customer probably meant. They can remember that requests from a particular department normally go to one person unless they involve finance, in which case they go somewhere else, except at quarter end.

Software cannot operate on folklore.

To automate a process, you have to define the inputs, ownership, decisions, exceptions, and desired outcome. You have to confront the places where the organisation depends on context that exists only in somebody’s head.

Automation can therefore be a forcing function for better process and systems design.

The objective is to question the steps, not reproduce every existing one in software. You must think in terms of systems and be critical of what you are studying.

Do we need this approval? Why are we asking for information we already have? Why does the work pass through three queues? Why does a person have to decide which team receives it?

Bad automation makes a poor process move faster. Good automation forces you to define a better process.

This principle matters even where you do not ultimately automate everything. The attempt forces clarity. It makes the team agree on ownership, inputs, and outcomes. It reveals exceptions that have quietly become the normal way of operating.

Where the process cannot be clearly described, it is unlikely to be consistently performed.

Make human routing optional

A person whose job is to read incoming work and decide where to send it is often compensating for a service that has not been designed properly.

That role may be necessary as a temporary safety net. It should not be a permanent architectural requirement.

Human routers become bottlenecks. They introduce delay, inconsistency, and dependency.

When they are experienced, they can make the process look remarkably effective because they know who really owns something and which wording indicates the underlying problem.

That knowledge is valuable. It should be captured rather than permanently rented from one person’s memory.

Design the service so that work can identify its own destination wherever reasonably possible. Use structured information, known customer context, service ownership, classification rules, and automation.

Where certainty is not possible, use a confidence threshold and send the genuinely ambiguous cases to a person.

Human routing should be the exception path, not the happy path.

This matters even more as AI becomes part of service delivery. AI can help interpret messy language, enrich requests, and recommend destinations, but it should not become a more expensive disguise for an undefined ownership model.

The system still needs to know who is responsible for what.

People are most valuable when they are exercising judgement, showing empathy, resolving genuine ambiguity, and making decisions that carry consequences.

Reading a form and forwarding it to another queue is not meaningful human involvement.

Build systems that can move work by themselves. Keep people available for the moments that deserve them.

Mind what accumulates

Never rescue a process silently

One of the most dangerous things a capable team can do is quietly prevent a broken system from ever appearing broken.

People fill in missing information, chase approvals, manually route work, and remember all the unwritten exceptions. They correct malformed requests and reconcile conflicting records without making any fuss.

The customer sees a service that just about works. Management sees acceptable performance. The people holding it together see the truth, but they are too busy compensating for the problems to fix them.

I am not suggesting you stop rescuing the customer. Everything else in this article argues that you should, and a service that deliberately lets somebody down to prove an internal point has just invented a new way of making its problems their problems.

The difficulty is that the rescue usually appears to cost nothing and leaves no trace. Somebody spots the malformed request, knows from experience which team it actually belongs to, forwards it, and gets on with their day. The customer is served, the report looks fine, and the thing that caused it is exactly as broken tomorrow morning.

So do the rescue, and then make it expensive to ignore. Record what happened. Note what the person had to know and what they had to do, because that is a fairly precise specification for whatever should have handled it instead. Count how often it happens and put that number alongside the others you review each week.

Work with a number attached to it gets prioritised. Work that lives in somebody’s head and costs them ten minutes a day does not, because those ten minutes belong to them rather than to the business.

Heroics are useful during an incident. They are a terrible operating model.

If you want to understand how much of your service depends on people covering for it, you can go looking on purpose, at a time you choose rather than one a customer chooses for you. Send a badly formed request through and see where it ends up. Ask the person who always knows to stay out of it for a fortnight.

Holidays do this for nothing. Very little reveals an undocumented process quite like the person who holds it being genuinely unavailable, which is one of the reasons I care so much about people taking their leave.

The aim is not to eliminate human involvement. It is to stop spending human judgement on work that only requires human memory, persistence, or pattern matching.

Do not become over-leveraged

There is a reflex in some teams that treats technical debt as inherently shameful, as though any of it existing at all is evidence that somebody did their job badly.

I do not think that is right. It is far more useful to think about technical debt the way you think about financial debt.

Debt is a tool. It is a large part of what drives an economy and, used sensibly, it is what allows a business to do something this year rather than in three years’ time. Taking some on is usually evidence of a deliberate choice about speed, not evidence of carelessness.

What people forget is what happens after the decision. When you create something, you own it. It has to be maintained, patched, understood, documented, explained to whoever arrives next, and eventually replaced. Nothing you build exists for free, and the bill does not arrive on the day you build it. It arrives every month afterwards, for as long as the thing survives.

There is nothing wrong with having a mortgage on your house. What is not fine is having a mortgage you cannot afford.

An over-leveraged technical team behaves much like an over-leveraged household. The weight starts to show, and it tends to show in one of two ways. Either the team can no longer move at a sensible pace, because every change has to be threaded carefully through things nobody wants to touch, or the quality of the work starts to slip because there is no room left to do it properly.

It also compounds. The more you are carrying, the more separate things demand attention, and the more your people spend their days switching between them rather than finishing any of them. Context switching is a tax you pay on top of the interest.

Refusing to make these decisions does not simply slow the work down, it chokes the creativity out of a team. Nobody offers up the interesting idea when they already know there is no room to build it, and watching your week disappear into servicing decisions somebody else avoided making is thoroughly demoralising. That is a more expensive loss than the debt itself, and a much harder one to reverse.

So be selective about what you take on, and be equally intentional about what you are prepared to remove. Most organisations are considerably better at adding than they are at subtracting.

Have one CRM, not three. Pick Microsoft or Google, not both. Teams or Zoom for your meetings, not both. Normalise where you can and actually make the call, because the alternative is quietly agreeing to feed all of it forever.

The Y-Statement from earlier does the same job here. A decision recorded properly, including the downside you knowingly accepted, is a decision you can still defend a year later when somebody asks why you did not do the other thing.

A good decision-making process does not only make you comfortable committing to something. It makes you comfortable deciding, deliberately and on the record, not to do something else.

Don’t stumble the wrong side of a moat

There is a pattern worth recognising in the way software vendors grow inside your business.

They arrive with one thing that is genuinely good, and that thing is usually displaceable. You could swap it out next year if you decided to. Then they add the features that make leaving difficult, and those features are rarely the ones you originally bought.

Come for the X, stay for the Y.

Some examples that are top of mind for me at the moment. Anthropic: come for the model, stay for the routines and Claude Design. Workboard: come for the OKRs, stay for the 1:1s. Miro: come for the multiplayer whiteboard, stay for the prototypes and wireframes. Slack: come for the chat, stay for the enormous ChatOps ecosystem and the growing pile of AI features.

To be clear, I have no objection to tools that do lots of things. Those are all good products, and breadth is frequently exactly what you want.

What I dislike is the tool you allow through the door for one purpose, which then creeps unintentionally into an increasing number of corners of your business. Nobody sits down and decides to do this. It happens one sensible convenience at a time.

Every one of those small conveniences makes the relationship a little stickier. That is fine while the tool is the best available answer. It becomes a problem when the tool grows, as tools do, and the part you depend on starts to lag behind. By that point you are no longer making a decision about one product. You are making a decision about nine things you had not really noticed you were buying.

It also quietly distorts how you assess everything else. You glance at something new and think, well, our existing tool does that, so we do not need it. Sometimes that is true. But you should be free to consider all of your options, and “we already own something that technically does this” is not the same statement as “we already own something that does this well”.

I think of those all-in-one televisions you used to be able to buy. A television with a built-in DVD player, a VHS player, and a little clock on the front. One device that does everything! Badly. With the most confusing remote control you have ever held.

A specific tool that does one thing will almost always do that one thing better. That does not mean you should go and buy forty of them, only that “it is already included” is weak evidence on its own.

All of this is far easier to describe than to do. Vendors work extremely hard at stickiness because it is their business model, and the worst thing that can happen to a SaaS company is account reduction. The packaging, the pricing, and the roadmap are all designed to make removing anything feel unreasonable.

So stay on top of it. Look at your ecosystem as a whole rather than one renewal at a time, and make the calls intentionally. Sometimes consolidating is exactly right and you should do it enthusiastically. Sometimes it is not, and the specialist tool has earned its place on the invoice.

I do not outright reject all-in-one tools. In fact, some all-in-one tools can be amazing, especially line of business systems with highly opinionated blueprints such as ConnectWise. But it should be a decision to go all-in-one in itself, not a decision to get each tool then stumble into an all-in-one.

Look after the people

Work hard and be nice to people

Years ago, Rob came back from a shop in Shoreditch with a poster that said, “Work hard and be nice to people.” It is difficult to improve on that as a philosophy for doing business.

Working hard while treating people badly creates a culture of ego, fear, and burnout. Being nice without doing the work creates a pleasant but ineffective organisation. You need both.

Being nice does not mean avoiding difficult conversations, tolerating poor performance, or agreeing to every request. It means treating people with respect. It means being direct without being cruel and remembering that the person at the other end of a difficult situation is still a person.

Customers notice how you behave when things go wrong.

Anybody can be friendly when the service is working and the account is profitable. Character becomes visible during incidents, disagreements, missed expectations, and commercial tension.

Take responsibility. Tell the truth. Do not become defensive. Focus on what needs to happen next.

Competence and kindness are not competing virtues.

The same respect should extend to the different functions inside a business.

Very early in my career at Bluhalo, Vimal Patel became something of a mentor to me. He once challenged a view that was fairly common among those of us back in the office.

We saw the sales team attending dinners, networking events, and conferences. They travelled frequently and appeared to be enjoying an endless succession of drinks and meals on expenses. Meanwhile, we believed we were the people doing the real work.

Vimal’s point was that it was probably not much fun at all.

Imagine going out several nights a week, constantly travelling, and repeatedly walking into rooms full of strangers. You have to begin conversations, make people like and trust you, remember names, absorb rejection, and remain energetic when you are tired.

All the while, you are carrying the pressure of working out where the next piece of revenue will come from.

In many businesses, the sales team is effectively trying to find the money that will fund everybody’s next pay cheque.

The pipeline never stops moving. Deals slip, budgets disappear, competitors appear, and last month’s success does not remove the need to sell again this month.

Respect your sales team. They bring in the calories that keep the company going.

That does not put them beyond criticism. Bad sales behaviour can create enormous problems for customers and delivery teams. Overpromising or selling work that cannot be delivered destroys trust.

The respect has to work both ways. Sales must respect the people who fulfil the promises, and delivery must respect the people who create the opportunity to make those promises.

Acquiring, serving, and retaining a customer are all part of the same flywheel, and if you drop one the system falls apart.

Use a meeting structure that works

Most meetings are bad because they have not really been designed. They mix status reporting, problem-solving, announcements, and decisions into an unstructured conversation.

The first topic consumes half the available time, the most important issue is raised with five minutes remaining, and everybody leaves with a slightly different understanding of what was agreed.

Use the EOS Level 10 Meeting structure. I have used it for around fifteen years and genuinely believe it can change the working culture of a team.

It is normally presented as a leadership meeting, but the underlying structure works far more broadly. I have used it with operational teams, functional leadership groups, and people coming together around a shared body of work.

The meeting follows the same rhythm each time. It begins by allowing people to arrive properly, then reviews the numbers, priorities, relevant people, customer headlines, and the previous actions.

Most of the meeting is protected for identifying, discussing, and actually solving the most important issues. It finishes by confirming actions, agreeing what needs to be communicated, and rating the quality of the meeting itself.

The official Level 10 Meeting structure is explained here.

The power comes from discipline rather than novelty.

The meeting happens at the same time, follows the same structure, and ends on time. Status updates do not consume the space intended for solving problems.

Issues are captured rather than allowed to derail the meeting, then prioritised so that the team works on what matters most rather than simply starting at the top of a list.

Run properly, it creates a dependable operating rhythm. Problems have somewhere to go. Actions have owners. Numbers are reviewed consistently and unresolved issues cannot hide indefinitely inside vague conversation.

One of the disciplines I value is the expectation that people are fully present.

In an in-person meeting, that meant putting away technology. That principle is harder in a remote world, where the laptop is also the meeting room.

I try to recreate the spirit of it by running the meeting through a shared Miro board or something similar. Everybody is looking at and contributing to the same workspace rather than disappearing into private notes, email, or Slack while the meeting happens around them.

The structure only works when you respect it. If every issue is discussed the moment it appears, if actions remain permanently incomplete, or if the meeting routinely overruns, it gradually becomes an ordinary meeting with some EOS terminology attached.

I have introduced a lot of people to properly run Level 10 meetings over the years. Almost every time, somebody remarks that it is one of the best meetings they have ever attended.

Most recently, that was Mark Michelman and Matthew Davenport, when I began working with them on my team about a year ago. That reaction says less about the brilliance of one meeting format than it does about the very low standard people have learned to expect from meetings.

Give meetings a purpose, a rhythm, and a method for reaching decisions. Respect everybody’s time enough to design the meeting rather than merely scheduling it.

Take time off, and do it properly

For a long time I let work be my number one focus, because I enjoyed what I was doing and honestly I was a bit addicted. It was the majority of Wirehive’s growth and it was exhilarating and consuming.

I immersed myself in work and treated the demands of the business as though they naturally deserved first call on my time. There was always a good justification.

I was building something, solving something, or carrying responsibility for something that mattered. None of those reasons was invented, but together they allowed work to occupy far more of my life than I realised at the time.

COVID rotated my priorities.

Like many people, I was forced to stop and look differently at how I had been spending my time. I realised that I had missed a meaningful chunk of my children’s lives by being so immersed in work. That is not time you can recover later.

Children do not pause while you finish an important period in your career. They do not stay the same age while you get through a difficult quarter, complete an acquisition, or wait for the business to become less demanding.

The years pass whether you make room for them or not.

Take your holiday.

Spread it throughout the year, book it well in advance where you can and, when the time comes, actually take it. This is especially important if you have a family.

It is very easy to let work consume the calendar. There is always a significant customer opportunity, a difficult project, a quarter end, a budget cycle, or some problem that apparently cannot survive your absence.

Leave enough empty space in the diary and work will happily fill all of it.

My balance is different now. I deliberately prioritise securing quality time with my family.

That does not mean work no longer matters, or that I have found some perfect separation between the two. It means family time goes into the plan as something important in its own right, rather than being left to compete for whatever remains after work has taken what it wants.

I currently work for a US-based company, so I accept that I will occasionally need to do things in somebody else’s timezone. A global business requires some give and take, and expecting every conversation to fit neatly inside UK working hours would not be reasonable.

My counterbalance is to put hard boundaries around the parts of the week that matter most.

On every UK working day, I have a hard-locked two-hour window between the end of school and the children going to bed. That is not an empty space in my calendar waiting for somebody to claim it. It is already committed.

I reserve one evening a week, Monday, for meetings that need to happen in US hours. Because I know Monday may run late, I allow myself to start later and spend time with Rachel instead.

The point is not to pretend the evening work has no cost. It is to acknowledge the cost and deliberately restore some balance elsewhere.

From Tuesday to Thursday I work from the office. On Friday I work from home and keep to UK hours.

None of this is perfectly symmetrical. Balance rarely is. It is a deliberate arrangement that allows me to meet the responsibilities of a global role without making my family absorb an undefined and potentially unlimited amount of disruption.

The important thing is that the boundaries are designed in advance. They are not renegotiated every time a meeting invitation arrives.

Book time away early. Put it in the calendar before everything else claims the space. Spread it through the year rather than relying on one large holiday to repair eleven months of exhaustion.

The same principle applies at the level of an ordinary week. Protect the time that matters before work discovers it is available.

When you are away, be away. Prepare a proper handover, make decisions in advance, and give other people the authority they need.

Avoid spending the holiday physically beside your family while mentally remaining at work.

Your family experiences your relationship with work even though they have no involvement in the business. They experience the cancelled plans, the half-present parent, the laptop at the dinner table, and the holiday spent checking messages beside the pool.

If the organisation genuinely cannot function for a week without you, that is not simply evidence of your importance. It is evidence that you have built a fragile system.

Taking leave exposes unclear ownership, missing documentation, and decisions that have been unnecessarily centralised. That can be uncomfortable, but it is useful information.

The answer is to improve the system, not to avoid taking another holiday.

There will be genuine exceptions. Sometimes a crisis happens at exactly the wrong time and responsible people step back in. The problem begins when everything is treated as an exception.

Do not confuse permanent availability with commitment.

A rested person makes better decisions, treats people better, and is less likely to turn every problem into a crisis. A leader who takes leave properly gives everybody else permission to do the same.

Work matters. So does the life the work is meant to support.

A note on working from home

My own balance includes working from home on Monday and Friday, while spending Tuesday to Thursday in the office with my team. That arrangement is something I’ve come around to over the course of the last five and a half years following COVID. I value the flexibility of working from home, but I have also become increasingly convinced that it carries a real cost to learning, relationships, and the development of teams.

A note from me: This section originally became a much longer part of this article. The more I wrote, the more obvious it became that it did not quite belong here. I also realised that I felt far too strongly about it to reduce it to a few comfortable paragraphs.

So I have broken it out into a separate article and expanded on it properly: Working from home holds your learning back.

The central argument is that productivity is not the same thing as development. A person can be highly productive at home while learning less, building fewer relationships, and receiving a much narrower view of how a business actually operates.

I think this is particularly dangerous for younger workers. Many established professionals entered remote working with years of context, confidence, and relationships already behind them. We cannot take somebody directly out of education, place them alone at home, connect them to a sequence of scheduled calls, and reasonably expect them to develop the same breadth of commercial understanding.

One of my favourite parts of running businesses and teams is helping people discover interests and build careers around them. Some of the conversations that change a person’s direction begin with nothing more substantial than leaning across a desk and asking a question. We cannot possibly nurture people as effectively when every conversation first has to earn a place in somebody’s calendar.

I still believe in flexibility, and I use it myself. I simply no longer believe that full-time home working is an equivalent substitute for spending a meaningful part of the week together.

Scrutinise people who never leave

People who refuse to take holiday are often praised for their dedication.

Be careful.

My accounting lecturer at college, whose name I wish I could remember and think may have been Neil, once told us a story from his time working in audit.

There was a groundskeeper at a cemetery who had not taken meaningful time off in years. He was dependable, knew how everything operated, and was always there to make sure things ran correctly.

Then he was hospitalised after an accident.

Somebody else had to cover his work and discovered that he had been keeping two sets of books. He had been skimming money from the organisation and moving it into his personal savings.

His refusal to take leave had not been extraordinary commitment. It had been part of the control system protecting the fraud.

While he was present, he could maintain both versions of reality. His unexpected absence broke the system and allowed somebody else to see what had been happening.

This is an extreme and deliberately nefarious example. Most people who refuse to take time off are not committing fraud.

The underlying organisational risk is still real.

Sometimes people make themselves indispensable because they cannot, or will not, build a machine that operates beyond them. They hold processes in their heads, become the only person with access to a system, and personally intervene whenever something goes wrong. They answer every question, approve every decision, and quietly compensate for weaknesses in the operation. This can happen without any bad intent.

In fact, it is often the most conscientious and productive people who create the greatest hidden risk. They care deeply, work incredibly hard, and solve problems before anybody else knows those problems exist. Their productivity shields the fragility beneath them.

At a glance, they appear to be your top performers. The work gets done, customers are happy, and problems disappear. The person appears irreplaceable.

Look more closely at what happens when they take a fortnight off.

Can somebody else perform the work? Are the processes documented? Do others have the necessary access and authority?

Are they building capability around themselves or accumulating dependency?

Consider what happens if they resign tomorrow. More uncomfortably, consider what happens if you need them to leave.

Call it the bus problem, a single point of failure, or a bottleneck. The metaphor does not matter. The risk does.

A genuinely great performer does not merely produce an exceptional volume of work.

They make the people and systems around them more capable. They document what they know, distribute authority, train successors, and reduce the organisation’s dependence on their continued presence. Their absence may be felt, but it should not cause the machinery to stop.

Mandatory leave, proper handovers, and sensible job rotation are not signs that you distrust people. They are healthy controls. They expose undocumented work, weak segregation of duties, and responsibilities that have become dangerously concentrated in one person.

Encourage people to take leave. Scrutinise those who consistently refuse.

Not because they must be doing something wrong, but because the organisation may have become dependent on something only they can see.

Service is what the customer experiences

The common thread through all of this is that service is not defined by the organisation chart, the process diagram, the platform you deployed, or the service level you reported.

Service is what the customer experiences while trying to get something done.

It is whether you made the journey easy and respected their time. It is whether you took ownership rather than exporting your complexity. It is whether the visible details inspired confidence and whether you were competent and decent when something went wrong. It is also whether you built a system that learns, or one that depends on good people repeatedly saving it.

Whether you are selling a service to the outside world or providing one to colleagues inside a larger organisation, those are the things that determine whether people trust you.

Trust takes time to earn, can be lost surprisingly quickly, and is one of the most valuable things a service provider can possess.

This is not a finished collection of rules. I doubt it ever will be.

Experience has a habit of adding new ones and occasionally forcing you to reconsider the old ones.

That is probably how it should be.