Diagnostic
The questions I ask every engineering organisation.
These are the questions that reveal where the real problems are. Not the symptoms. The causes.
Delivery
Do your teams consistently deliver what they commit to?
Missed commitments are never random. They are a signal of unclear requirements, unrealistic estimates, insufficient process, or a team that has learned not to say no. The pattern matters more than any individual miss.
Team
Is your engineering team structured around how the business actually works?
Team structure is strategy made visible. The way you organise your engineers determines what they can ship, how fast they can move, and where the bottlenecks will form. Most teams are structured around the past, not the future.
Security
Could you pass an ISO27001 audit today?
Security posture is one of the first things an investor examines. Gaps that feel manageable internally become deal-breakers when a third party looks at them with fresh eyes. The time to find them is before the process starts.
Knowledge
If your three most senior engineers left tomorrow, how long before production broke?
Key-person dependency is one of the most common and most underestimated risks in growing engineering organisations. It is invisible until it is not. By then it is usually too late to manage calmly.
Process
Does your development process create predictability or does every sprint feel like a negotiation?
Agile done well creates rhythm and predictability. Agile done badly creates the illusion of process while preserving all the chaos. The difference is visible within a single sprint if you know what to look for.
Architecture
Is your architecture a deliberate decision or the accumulated result of shipping under pressure?
Most architecture debt is invisible until the system starts slowing down. By then it is expensive to fix. The right time to review your architecture is before you hit the scaling wall, not after.
Budget
Can you explain your IT spend to the board and defend every line of it?
Unstructured technical budgets are a red flag for investors and a source of constant friction with non-technical leadership. A well-structured budget is not just financial hygiene. It is a strategic tool.
Roadmaps
Does everyone in your organisation agree on what gets built next and why?
Without a formal prioritisation mechanism, roadmaps become negotiation arenas. The loudest voice wins, technical debt gets deferred indefinitely, and the team loses confidence that what they build actually matters.
APIs and integrations
Are your APIs designed for the partners you want or just the ones you have?
Poor API design is one of the most expensive mistakes to fix once a product is in market. Third-party integrations built on shortcuts create dependencies that compound. Standards matter most before the first integration, not after the fifth.
Technology and strategy
Is your technology stack a deliberate strategic choice or the result of whoever was hired first?
Technology selection has long-term consequences that are easy to underestimate in the moment. The wrong stack creates hiring problems, performance ceilings, and migration costs. The right stack, chosen deliberately, is a competitive advantage.
Funding and due diligence
If a VC technical reviewer walked into your codebase tomorrow, what would they find?
I have passed three VC due diligences from the inside. The teams that struggle are the ones who discover their problems at the same time as the investor. The teams that pass are the ones who already know where every body is buried and have a plan for each one.
DevOps and IaC
How long does it take to go from a completed feature to production and how much of that is manual?
Manual deployment processes are a tax on every engineer in your organisation. They create risk, slow feedback loops, and make every release an event rather than a routine. Infrastructure as Code is not an advanced practice. It is the baseline for any team that wants to scale.
AI readiness
Do you know where AI and agentic systems fit in your product and where they do not?
The difference between an organisation that uses AI effectively and one that wastes six months on a proof of concept is not technical capability. It is architectural clarity. Knowing what to automate, what to augment, and what to leave alone requires judgement that comes from building these systems under production constraints, not from reading about them.
How many of those gave you pause?
If more than two of those questions gave you pause, you already know something needs to change. The only question is how quickly you want to see it clearly. Book the call directly below.