From Scale-Up to Scale-Out: 5 Minutes With Henry Lockwood

The journey from a nimble startup to a high-growth scale-up is fraught with challenges, from culture shifts to the ever-present threat of tech debt. We sat down for “5 Minutes With” Henry, a veteran in scaling engineering teams and operations, to discuss the critical changes an organization must embrace to navigate this transition successfully. He shares his insights on everything from preserving velocity and bridging the tech-business divide to the subtle signs that your operating model is no longer fit for purpose.

 

Chris: You’ve scaled engineering teams and operations in growth environments, when you’ve moved from “startup” to “scale-up” mode, what are the top changes in how the organisation must operate (culture, leadership, structure) to avoid growing pains?

 

Henry: What works when you’re 10 people – whether that’s in a team, a function, or a company – breaks before you hit 100. The scale means you can’t just gather everyone around a table to discuss how we build the next 3 months; you can’t wave across the office or ask questions in #general; you can’t memorise when everyone is going on holiday and therefore the work needs to be covered. That’s when you need enough structure and enough process.

Structure is not exciting, but it’s useful. It means you don’t need everyone in the org to be always-on; you have decision-making structures that still work when a leader is on holiday. You have a clear set of criteria for when you phone someone at the weekend. And you can allow people to specialise; you don’t want a company of specialists alone, but there are times when you absolutely need that deep expertise.

Culture and communication change, significantly. In the same way that you can’t make all decisions around the lunch table, all-hands meetings are no longer enough on their own to keep everyone informed. You need documentation to capture tribal knowledge; you need structured async comms (Slack or email) for announcements; and you need a culture of communication.

Finally, you need to preserve velocity. Startups succeed because they’re fast; scaleups risk dying because they aren’t. This means empowering squads (not just in your tech teams) to own outcomes, not tasks; it means ruthless scope management; and – hardest of all – it means letting go. As a scale-up founder, you can’t take every decision; you can’t be in every room. You have built a great startup and hired great people; now trust them to take it further.

 

Balancing Business & Technology

Chris: You describe yourself as thriving at the intersection of technology and business transformation. In your view, when a company is scaling, where is the most common misalignment between tech leadership and business leadership and how can you bridge that early?

 

Henry: It’s all to easy for tech to turn into a feature factory. Business leaders optimise for revenue: “We need feature X to delivery $$ in revenue by Q3”.  Tech leaders build this, and fast; then you hit the inflection point where tech debt starts to get in the way. Each change takes a little longer than the one before. Feature X becomes a nightmare: late, janky, and hard to use.

The bridge is in communication. Instead of saying “we’ve got too much tech debt”, say “we’re starting some initiatives to improve future engineering velocity. We’re going to reduce our spend on firefighting from 40% to 15% of engineering capacity, by rebuilding some of the problem areas.”

Everywhere I’ve worked has had tech debt of some form; the companies that succeeded in moving past it were those where we made a consistent effort to understand where our engineers were spending time: was it keeping the lights on, was it building new features, or improving existing features?

In my career I’ve bridged both sides of this divide, and the effect of having that conversation with everyone in the same room can be huge: we get people hearing each other’s language, understanding what needs to be done.

 

When to Hire the Next Layer of Leadership

Chris: At what point (in terms of growth metrics, product maturity, market penetration) did you realise “we need a new senior leader/VP layer” rather than keep pushing with the founding team? What criteria did you use to make that call?

 

Henry: There’s no single metric here, but a stack of criteria: if you have multiple of these signals, look at hiring a new layer. This won’t happen in all areas at the same time: Tech, Revenue, G&A, all grow at different speeds.

Strong signs that you’ve become a bottleneck, not a leader:

1. Founders & leaders are context-switching more than thinking. You can’t go deep on anything and you’re always in meetings.
2. Decisions are late or weak. You’re deciding without context, or putting everything off until you can understand.
3. Your span of control is absurd. Managing 12+ direct reports is a strong risk signal. You can’t do meaningful 1:1s at that scale.
4. Your high performers are leaving because there’s no growth path, or because they’re drowning in coordination.
5. Information breaks down; teams don’t know what other teams are doing. You hear everything third-hand because the “everyone knows” network has collapsed.

Don’t hire if you can solve it another way: say no to noise, push down authority, build clearer processes, or get better tooling.

Do hire if you need specific domain expertise, or if you’re truly at capacity on strategically important work.

 

Susceptibility to Disruption

Chris: In fast-moving markets, tech stacks and business models can get left behind. Looking back what signs did you see in previous roles of “we’re being disrupted” or “our operating model is no longer a fit” and how did you respond?

 

Henry: Builder.ai’s existential warning signs:

The most obvious one was revenue model vulnerability – we had massive cash burn on a labour-arbitrage model that couldn’t survive margin compression. When your unit economics only work with constant capital infusion and you can’t raise, you’re already disrupted.

But the subtler signs were there earlier:

• Customer acquisition cost creeping up while competitors launched no-code tools
• Win rates declining in competitive deals – we’d lose on price or delivery speed
• Engineering talent harder to retain because the tech stack felt dated compared to market
• Lack of focus: we’d built internal tools, e.g. video-conferencing, work tracking, and auth&auth, where we should have used market leaders instead.

 

Software AG’s slower-burn disruption:

Integration middleware being hollowed out by cloud-native approaches. The signs:

• Longer sales cycles as customers delayed decisions, waiting for cloud strategy to crystallise
• Deal sizes shrinking – customers buying point solutions rather than platform
• “We need to modernise” heard at every QBR, but the core product architecture was fundamentally legacy
• A decision in 2014 that “Cloud is a fad”, meaning we were late to that wave.

 

I’ve long been a fan of doing few things, well. This means keeping an eye on your portfolio, looking at what’s performing (and what isn’t), and killing your darlings. This can be your dying products (don’t invest in new features, and be ready to sunset them); it can be a new bet that isn’t delivering results. Don’t hold out for one more quarter. Pull the plug.

I’d change things as well. In transformation, it’s tempting to take a gentle approach to keep people engaged and avoid too much disruption. Don’t. The muscle memory of the old way keeps people stuck. You need to jolt them out of that, hire enough new talent who have built the new way (in your industry or others), and coach the existing teams. Coach them hard, and – regrettably – let go of the ones who won’t learn.

 

Product Development

Chris: In one of your posts you referenced “Thinking by Doing”. How do you convert that mindset into day-to-day operational practice within a scaling company? For instance, how do you ensure it doesn’t just become “we build fast and iterate” but maintain discipline?

 

The art here is to think about when you need fast, and when you need good. Separate your modes of working, and make it explicit.

For exploration, above all else, define what you want. You should aim to answer one or two questions, and know when you’ve answered them. For example, “will users understand this?”, or “can a machine-learning model do better than our current approach?”

Time-box it. Allow half a day (max) for prototypes. Allow 2 days max for a research spike.

Make it disposable by default: ugly code is fine; testing is for tomorrow; documents are for next month.

That way, you know when to stop.

For production mode, you need disciplined delivery. You can still do this fast, but you’re building for the longer term: whether that’s a month, a quarter, or a year, this is code (or process) you expect to stick around.

The disciplined process I aim for is:

1. Think about what you’re building, who you’re building for, and why you’re building it.
2. Think about how long it needs to last; don’t over-engineer something that will last a month, but don’t under-engineer something that’s the core of the next year.
3. Use tests wherever possible: that way you know if something’s working, if something’s recently broken, and if it does what you want.
4. Monitor & measure things: production environments, what’s getting in your team’s way, and how much money you’re making.

Now you’ve got to make this a reality. 5 things make this possible:

1. Set an explicit budget – 10%-20% is good – for exploration time. This can be spikes or prototypes; if teams don’t have this time, they’ll just hack in production mode because they still need to learn and explore.
2. Don’t put process around experiments. Define your hypothesis and your timebox, then get out of the way.
3. Force the transition. If it was built in exploration mode, it must be thrown away, no exceptions. Don’t tell yourself “we’ll clean it up later” – I’ve been guilty of this, and you never will.
4. Review what you learned, not what you built: show the prototype, but talk about the insights. What did we discover? What risks have we eliminated?
5. Walk the talk: make sure your tech leads visibly throw away code that doesn’t work. Publicly experiment. Publicly fail, and share what you learned from it.

 

Global Workforces and Expansion

Chris: If you’ve scaled beyond one geography: what are your top considerations when expanding engineering/operations into new regions (regulation, talent, culture, infrastructure) and what’s one thing most companies under-estimate?

 

Henry: I’ve always inherited a geo footprint, often too spread. If you’re going for an in-person culture, don’t add a new site until your smallest site is at least 15 people (about the minimum to maintain a local culture and momentum). If you’re fully-remote, make sure you have a suitable employer of record in country; the sweet spot for moving from EOR to a legal entity is around 10-15 people.

The thing I see missed most often is the impact of timezones. People expect to collaborate across cultures by now; communication has different defaults in different countries, but if you’re working with teams at a 12-hour offset, you can only speak to them at the start or end of your working day. You have to be really good at async communication to make that effective.

 

Tech Debt vs Innovation

Chris: As teams scale, managing tech debt becomes necessary. How do you strike the balance between continuing to build new features vs fixing/rewiring core systems and what governance helps you do it effectively?

 

Henry: I don’t think this is primarily about teams scaling, so much as codebases. There’s no perfect balance, so you need a framework for deliberate trade-offs. Here’s what’s worked for me in the past; I’d also recommend Lou Franco’s book.

Make tech debt visible in business terms. If you make the overhead visible – incident rate & MTTR, engineering capacity split – you present a clear cost to the tech debt. This shifts the conversation from “why aren’t you shipping faster?” to “what do we need to fix?”

Categorise debt. It’s not all created equal. Security vulnerabilities, compliance risks, scalability blockers, major customer-visible bugs: fix them right away. High-drag debt that makes it harder to build new features (or change existing ones) is less visible to the business, but needs advocating for. Divide and conquer if you can. If the code’s just ugly and hard to read, or if it’s undertested but works anyway, fix it opportunistically when you’re changing that area.

To prevent problems growing, think first: will the current architecture support this major new feature? Track debt that you know you’re taking on (e.g. a Confluence page) – make it public. As an engineer, leave code cleaner than when you found it; small improvements compound.

Finally, never put your prototypes in production. You won’t clean them up later.

 

Team Morale

Chris: When you bring in experienced leaders (or reorganise) in a scaling team, how do you maintain or uplift morale among engineers who joined the company when it was small and “flatter”?

 

Henry: This is tough. Really tough. You’re changing the environment they’re used to and they signed up for.

Early joiners choose startups because they’re small; they offer autonomy, direct impact, and access to leadership. Now they’ve got a manager they didn’t choose, processes they didn’t design, and decisions made elsewhere. It can feel like a betrayal.

As a leader, it’s critical to be fair. Don’t pretend this is all upside, even if you’re promoting from within. Acknowledge the pain in team meetings: acknowledge the upside as well (more time to focus, clear career paths, and we only need to do this because we’re doing well). But be fair, and be honest.

Protect the appeal of the company. Keep that autonomy, and don’t hire command-and-control managers. Create visibility, so your engineers are still able to demo what they’ve built; still able to see their contributions making a difference. Don’t let them become a cog in the machine. And keep them learning: juniors should still work on interesting projects with experienced mentors; seniors should have access to strategic context, even though they’re no longer in every meeting.

I mentioned career paths earlier: make sure these are clear. Keep a Staff/Principal Engineer track with influence but no direct reports; let strong ICs lead initiatives and shape the architecture. And pay them well; a Staff Engineer should be on par with a first-line manager, else they may want to move to management. Don’t let great ICs become mediocre managers just because it pays more.

And involve your best ICs in hiring. Your most senior and your most tenured engineers should have a veto on any Head/Director of Engineering hire. Ask them “What would make you excited to work for this person?” – for me, the answer has always been: “Is this someone I can learn from?”

The mistake I’ve seen have the biggest impact is relying too much on tenure to select managers: not all your early hires will make good managers, and that’s fine. You need more engineers than managers anyway.

 

What is your “North-Star” metric for leadership effectiveness?

Chris: If you were asked “how will you know you are doing a good job as the engineering/business transformation leader in the next 12 months”, what metric(s) do you monitor and why?

 

Henry: A leader is there to achieve 2 things: ensure that decisions are made (fast and well), and ensure that the team have what they need to do good work. Metrics on decisions:

• Decision speed: time from “decision needed” to “decision made and communicated”, for all decisions above a certain size (e.g. budget > £50k, affects >10 people).
• Decision success: percentage of these decisions that need major revision (or reversal) within 6 months.

My supporting metrics address organisational health:

• Cycle time (idea –> production): are we accelerating the business?
• Unplanned work %: are we building or firefighting?
• Engagement scores from directs and skip-levels (if my skip-levels are disengaged, that’s my failure for not coaching my direct reports).
• Attrition in high performers: each time I lose an A-player, I want to understand why. Sometimes it’s natural: they just love startup chaos, and we’ve scaled past that. Usually it’s a problem; we lost them 6 months ago and they’ve just found the perfect role.
• Revenue/cost outcomes from transformations: we projected a saving (or revenue) of £X; what did we deliver?

I’ve seen decision paralysis kill companies. Wrong decisions can be corrected; slow decisions compound. It’s easy to forget that “we’ll decide next week” is a decision in itself; it’s a decision to slow down. It’s a decision to become stale. It’s a decision to fail.

My real test: if I left tomorrow, would the organisation still make good decisions quickly? If so, I’ve built capability. If not, I was just a bottleneck with good judgment.

 

If you are interested in doing a “5 minutes with” with us then please do drop me a note and get in touch today…