10 Questions Every Leader Should Be Able to Answer

Most leaders have a good instinctive sense of how their business is doing commercially — revenue, growth, customer numbers, cash in the bank. Far fewer have an equally clear picture of the technical foundation underneath it. That’s not a criticism; it’s simply not what leaders are trained or expected to track day to day.

But a handful of straightforward questions can tell you, fairly quickly, whether your systems are in good shape or quietly accumulating risk. None of these require a technical background to answer — if anything, the questions you can’t answer confidently are the most useful signal of all. Here are the ten worth asking yourself.

1. If your most technical person left tomorrow, would the business keep running?

Every business has some concentration of knowledge in one or two people. The question isn’t whether that risk exists — it almost always does — but whether anyone’s aware of it and has a plan, or whether it would simply cause chaos.

2. Could a new hire understand how your systems fit together without asking three different people?

If the answer requires tribal knowledge scattered across your team rather than something written down, that’s not a hiring problem — it’s a sign your systems’ design lives in people’s heads rather than in the systems themselves.

3. Do you know where your single points of failure are?

One server, one integration, one manual process that everything else depends on — most businesses have at least one. The businesses at risk aren’t the ones with a single point of failure; they’re the ones who don’t know they have one.

4. Could you answer “how many active customers do we have?” in under a minute?

Simple operational questions should have simple, fast answers. If getting a clear number requires cross-referencing multiple systems or chasing down several people, that’s a data silo costing you more than you’d guess.

5. If you doubled in size next year, what would break first?

Not “would something break” — something always does — but do you have any idea what, specifically? Leaders who can name their likely breaking point are already ahead of the ones who’d only find out when it happens.

6. When did you last review what your tools and infrastructure actually cost you?

Costs creep quietly, especially with cloud infrastructure and AI tools priced on usage. If it’s been a while since anyone looked properly, there’s a reasonable chance you’re paying for waste you’re not aware of.

7. Is your customer and business data something you could hand over cleanly if you needed to?

Whether that’s for a new hire, a new tool, an investor, or a buyer, this is a good proxy for how healthy your data actually is. If the honest answer is “it would take weeks to untangle,” that’s worth knowing now rather than discovering under pressure.

8. How many of your current tools were adopted under time pressure, without much evaluation?

Not a criticism — every growing business does this. But knowing roughly how many of your systems were quick fixes rather than deliberate choices gives you a sense of how much hidden technical debt you’re likely carrying.

9. Do you know what it would cost, in time and money, to switch away from your most important vendor or platform?

You don’t need to actually switch. But not knowing the answer means you don’t know your own negotiating position, and you won’t know if that cost has quietly grown to an uncomfortable size.

10. Is there a plan for your technology, or is it being decided reactively, tool by tool?

This is the question that ties the others together. Businesses with a plan make each new tool or system decision in the context of where they’re heading. Businesses without one make each decision in isolation — and end up with the accumulated result of nine separate “good enough for now” calls.

What your answers tell you

If you answered most of these confidently, that’s a genuinely good sign — you likely have a clearer picture of your technical foundation than most businesses your size. If several answers were a shrug, or “I’m honestly not sure,” that’s not a crisis. It’s simply information nobody had gathered and organised yet, which is exactly what a proper architectural review does.

The value of this exercise isn’t the score. It’s that leaders who can answer these questions make faster, better decisions — about hiring, about growth, about fundraising, about which fires are actually worth fighting first. The ones who can’t tend to find out the hard way, usually at the worst possible time.

---

Ashdown Systems helps UK startups and SMBs get clear, honest answers to exactly these questions — and a plan for what to do about the ones that came up short. If any of this sounds familiar, get in touch.

If you run a startup or SMB in the UK, there’s a decent chance you’ve never used the phrase “Solutions Architecture” in a sentence. That’s fine — most business owners haven’t, and most don’t need to. But there’s also a decent chance you’re already living with the exact problem it solves, without having a name for it.

Here’s a scenario that might sound familiar. You started with a handful of tools: an accounting package, a CRM, maybe a booking system or an e-commerce platform. Each one made sense on its own, solved an immediate problem, and got switched on quickly. Eighteen months later, you’ve got data trapped in five different places, someone on your team spends half a day a week manually copying numbers between systems, and nobody’s entirely sure which version of the customer list is the “real” one.

Nothing broke. There was no single bad decision. It just… accumulated. That accumulation is exactly what Solutions Architecture exists to prevent — and to untangle once it’s already happened.

So what actually is it?

Think of it like the difference between building an extension on your house room by room, versus getting an architect to draw up plans first. You can do the former — plenty of people do — and each individual room might be perfectly fine. But without a plan that considers how everything connects (plumbing, load-bearing walls, where the light falls), you end up with awkward compromises baked into the structure, ones that are expensive to fix later because now there’s a wall in the way.

Solutions Architecture is that planning discipline, applied to how a business’s systems, tools, and data fit together. It’s not about writing code. It’s about answering questions like:

• What are we actually trying to achieve, and what does the business need from its systems in 2 years, not just today?
• Which tools should talk to each other, and how?
• Where’s the single source of truth for our customer data, our orders, our finances?
• If we double in size next year, does this setup hold — or does it fall over?

A good Solutions Architect sits above any one piece of software. They’re not selling you a CRM or a cloud platform — they’re figuring out what combination of things (which might include tools you already own) actually serves the business.

Why this matters even if you’re not “technical”

There’s a common assumption that architecture is something for tech companies — SaaS businesses, software vendors, engineering-led startups. It’s true that those companies need it. But arguably, non-technical businesses need it more, precisely because they don’t have anyone in-house whose job it is to spot the problem forming.

A tech company usually has an engineer somewhere who winces when three systems don’t talk to each other. A retail business, a professional services firm, a hospitality group — they often don’t have that person. The disconnect between systems doesn’t show up as a technical error message. It shows up as a Friday afternoon spent reconciling spreadsheets, a customer getting the wrong invoice, or a new hire who takes three weeks to understand “how we actually do things here” because it’s never been written down or built into the systems themselves.

None of that requires you to understand databases or APIs. It requires someone who can look across your whole operation, ask good questions, and design something that fits — then translate it into terms your team can actually use.

What this looks like in practice

For an SMB, Solutions Architecture rarely means a six-month project with a five-figure price tag. More often it looks like:

• A short discovery process to map out what tools you’re using and where the friction actually is
• A clear, plain-English plan for how things should connect — what stays, what goes, what gets automated
• Recommendations that are proportionate to your size, not “enterprise” solutions you’ll grow into eventually
• A roadmap that means the next tool you buy fits into a plan, rather than becoming yet another island

The goal isn’t complexity. It’s often the opposite — removing steps, removing manual work, removing the version-control chaos that builds up quietly over time.

The real cost of not doing this

The businesses that feel this most acutely are usually the ones growing fastest. Every new hire, every new customer, every new system you bolt on either compounds a good foundation or compounds a shaky one. The compounding is the same either way — it’s just a question of which direction it’s working in.

The good news: you don’t need to have a technical team, or even a big budget, to start doing this properly. You just need someone to ask the right questions before the next tool gets bought, not after the third spreadsheet reconciliation of the month.

---

Ashdown Systems helps UK startups and SMBs design systems and technology that actually fit how their business works — no jargon, no over-engineering. If any of this sounds familiar, get in touch.