#scale #growth - 20 mins read

Diagnose and overcome common barriers to scale

There comes a point when the growth of your product and therefore your business begins to slow, or simply isn’t going as fast as you need.

A time when everything begins to feel morale-sappingly more drawn out.

But the good news is that it’s relatively straightforward to diagnose the underlying causes of this deceleration. And there are patterns to work around these causes, or even avoid them entirely.

This article describes some of the most common barriers I’ve seen, their typical underlying causes, and what you can do to push through them. It’s aimed primarily at CEOs, and product engineering leaders (CxOs, VPs, Directors, Heads of), who are in the best position to influence these areas.

It's a little longer than my typical posts and covers a lot of ground, so perhaps one to bookmark and come back to.

How these barriers often manifest

It tends to present in one of three ways:

“We aren’t shipping fast enough,” or

“We need to deliver feature x in the next six months to gain an advantage on competitor y / placate customer z, but the next eight quarters are already packed out,” or

“We can’t sign up enough new customers because a) our tech stack won’t support any more, or b) we can’t onboard them at a fast enough rate.”

These are all tightly coupled, and often share causes which themselves are interrelated.

Root causes of inertia

Whilst the interdependencies illustrated above make this a bit of a rat’s nest of complexity, the good news is that addressing any one area can have a positive knock-on effect on several other areas.

Underlying causes

I've drawn the line at 14 discrete root causes:

Poor cross-team alignment

Taking a step back, it’s a given for me that the best products are built by cross-functional teams. If you don’t work in cross-functional teams, then start by looking to change that.

74% reported an increase in performance on switching to cross-functional teams - Deloitte, Organizational performance: It's a team sport

As organisations grow, this begins to break down without real and intentional focus.

Every additional team that you spin up adds cognitive load to your existing teams, and introduces overheads and risk.

Building on Brooks’s Law, the lines of communication also increase exponentially as each new team is created, compounding this effect.

Brooks's Law

Source - DevIQ, Brooks's Law: Understanding Its Implications in Software Development

Typical indicators of this could be:

One team goes to release a feature only to find they’re blocked by another team
Two teams unknowingly build the same or similar things
There is a disconnect between team objectives and business strategy
Releases become unwieldy
Teams flag this as a source of pain in their retros

The gold standard here is to lay foundations for this as you move from one team to two, but it’s not the end of the world if this hasn’t happened. You can retro-fit all of these regardless of how far along you are in your journey.

Recommendations:

Read Team Topologies to better understand the challenges around multi-team organisations, different types of teams, and how best to set them up for optimal interaction.
Be intentional about your organisational design from day one, being mindful of Conway’s Law. Be prepared to change your organisational design every few years - perhaps even more frequently - as you mature and the product, tech, and market landscapes evolve. I wrote a high-level overview of how I’ve seen product engineering functions shaped as organisations grow.
Continuing on the organisational design theme, consider the make-up of your teams and the supporting roles outside of teams. The aforementioned "How to shape a product function" article gives a few pointers on how the introduction of “Heads of…” and a move towards more of a tribe model can help foster alignment. Regularly assessing the blend of skills within your teams versus what they actually need is also recommended. Is one person overloaded covering product, design, and delivery? Is the product now big enough to warrant a dedicated content designer? Here’s Hyperact’s take on the core roles of a team, and when the introduction of specialists can have the biggest impact.
Create team artefacts that outline the domain and workings of the team. Team Topologies’ Team APIs is one way to do this, or you can go a bit further with Hyperact’s Team Canvas Miro template.

Unclear focus

This can often amplify the previous root cause (cross-team alignment), but has the potential to do much more damage, rusting up your once free-flowing growth engine.

It’s the most natural thing in the world to want to do all of the things, and do them all as soon as possible. But the more you strive for this, the less likely you are to succeed. It takes a huge amount of energy, rigour, and discipline to continually set and reset focus. If you don’t have focus, it’s incredibly unlikely that you’ll continue to scale successfully, and this only compounds and gets harder over time.

Fewer priorities equals greater progress

Source: Hustle Badger, How to write a great product strategy

How you answer the questions below will be fairly indicative of where you are on this:

What are your organisation’s aims, on various time horizons e.g. quarter, year, five-year?
What are your team’s aims, on various time horizons e.g. quarter, year, five-year?
How will you objectively measure your progress towards these aims?
Are the bulk of the things that you’re working on either gambles to move you towards those aims, or things that you’ve intentionally prioritised to enable you to work towards your longer-term goals faster?
Are you able to defer stuff that doesn’t move you towards these aims?

If you don’t have clear aims, aren’t actively tracking progress towards them, or really struggle to dedicate the bulk of your effort on gambles to move you towards your aims, then you likely have a focus problem.

So what can you do? First and foremost, be decisive and clear. In an ideal world, this direction should come from the CEO, who sets the broader direction in the form of a business vision and strategy, then product and engineering leadership set the direction from a product perspective, with cross-functional teams then given space to set their own goals, particularly over the smaller time horizons.

In many cases, perhaps most cases, it doesn’t quite happen like this. I’ve seen:

Product engineering leadership set the direction in a vacuum without the CEOs direction
Product engineering leadership work with the CEO to set the direction
The CEO to set the direction from both a business and product perspective
Teams try and set the direction from the ground-up

There is no silver bullet here. I’ve seen all of these different patterns both succeed and fail, to a greater or lesser degree. The key is to be intentional and systematic about this, and to do it collaboratively - that is to say not on your own in isolation.

Where to start? If you have nothing on this front, start with a snap strategy. It’s not as scary as you may think to come up with a cohesive, robust strategy. And decision stacks are incredibly simple yet powerful tools to visualise the essence of one. A quarterly cadence of objectives and key results (OKRs) is a sensible default when it comes to setting and tracking goals, but I’ve seen OKRs fall down more than I’ve seen them stand tall. They require ownership, discipline, energy, and over-communication. And you don’t need to (and probably shouldn’t) use these “out of the box”. Go with what works for your teams and your organisation.

And the biggest killer I’ve seen here? Going too broad too early with target customers. This is where your strategy comes into its own.

Too much work in progress

This is one of the more discrete underlying causes I’ve called out. There is always more stuff to do than there is time, and it’s another natural development for a team to spread the focus too thinly. Where there is an imbalance in the profile of work a team undertakes, this can often lead to spikes in unplanned work which can then normalise overloaded work in progress, and make it hard to pull this back.

Cutler's view of balancing product priorities

Source: John Cutler's TBM 4952 Your Calendar, Your Priorities

The best way I’ve found to assess whether you’re in this trap at a team level, is to retrospectively look at what you’ve delivered over the last few months. How much of it was unplanned? How many threads have you covered? How many had an impact? How much moved you towards your aims? This may tell you that you’re targeting too many contexts, and is something you can address by consciously reducing your aims and trying to tackle one at a time, whilst having the discipline and courage to say no to work that doesn’t move you in that direction.

In terms of a team actually having too much in flight, it could be as simple as having WIP limits on a jira board, or being vocal about this in agile ceremonies, and championing slack over being busy for the sake of it.

Where this can be more difficult is at organisational level, whereby the organisation as a whole is spreading itself too thin. Strategic thinking, planning, and executing is the best way to resolve this, as outlined in the “Unclear focus” section.

Having too many competing priorities rumbling along in parallel only ever results in poor outcomes and burnt out people.

Centralised decision-making

The reality is that leaders get further away from customers and products as an organisation grows, and are increasingly worse positioned to make decisions based on product and customer insight. I’ve seen this pattern over and over, as a founder, CEO, or early-stage leadership team becomes a bottleneck for progress at pace.

The moment you’ve got three or more teams vying for central approval on priorities or product designs, you’ll have overloaded your decision-making mechanism. It just doesn’t work. You’ll struggle to find time with them.

To avoid inertia setting in, you need to ensure that your teams can make decisions at pace with minimal, or better still no involvement from leadership. A few things that can help here:

Product principles
A clear, regularly communicated strategy, with clearly defined cascading aims for each team
Good org design to foster cross-team alignment
Excellent async comms

Lack of delivery management

By delivery management, I mean a team collectively owning and driving:

Enablement - having the tools and setup to do their thing
Flow optimisation - getting through stuff at a healthy rate
Focus - concentrating on things that move the needle
Continuous improvement - striving to better themselves

I wrote about this in a bit more detail in my "Why delivery management doesn’t happen by accident?" article, but the main thing I’d add is that this tends to get more of a focus as things slow down. You can get away without this as a start-up when licences are flying off the shelves, but its not uncommon for leaders to start pointing fingers in this direction as things slow down. And that isn’t as bad a thing as it sounds - there is always room for improvement within teams in this regard.

Poor organisational design

This is a big contributing factor to poor cross-team alignment, but it’s bigger than this. Yes, one of the most impactful things you can do is be intentional in the shape, size, and domain of your product engineering teams and corresponding architecture a la Team Topologies and "How to shape a product function", but there’s a lot more to it than this. Product engineering is simply not enough.

Is your leadership team structured in a way to facilitate alignment and fast decision making?

How is communication and collaboration enabled between product engineering and all of the other key areas of your organisation. Sales? Customer experience? Client / account management? Marketing? Ops? Finance? Legal? People Ops? Data?

If you aren’t intentional about this, it will be forever sub-optimal, and only ever worsen as an organisation grows.

Customer support challenges

This is another one that I’ve written at length about previously, in "Death by a thousand bugs".

If you are successful, and particularly if you're B2B and/or in a highly regulated industry, you will become overwhelmed managing customer support issues, or service desk tickets, or whatever terminology use. Some indicators that it’s definitely time to get on top of this are:

More than 20% of the work items your team work on are customer support issues
There are multiple routes in to your team for customer support issues
There are multiple regular meetings in which customer support issues are discussed
Customer support issues are getting through to the team at a consistently higher rate than you can work through them

And what can help get you through this? Thankfully quite a lot:

🔦 Acknowledging support is a thing: Recognise that support issues exist and impact teams, the organisation, and customers, and address them in meetings or one-to-ones.

📝 A standard way to record issues: Use a simple, flexible template to capture essential information about issues, ensuring clarity without unnecessary rigidity.

🎯 A central tracking system for issues: Implement a shared tool, like Jira or Google Sheets, to centralise support issues, ensuring easy access and visibility for all.

🔝 A clear prioritisation mechanism: Create a straightforward prioritisation framework, like a tiered classification system, and reference it consistently to manage issue focus.

⏳ A baseline service level agreement (SLA): Establish SLAs to set goals for response times based on issue severity, ensuring timely resolution and continuous improvement.

🛣️ A single route in to the team to discuss support: Designate a dedicated communication channel for support discussions, maintaining a streamlined, transparent flow of information.

👥 One or more people accountable for support: Assign dedicated ownership of the support process to ensure focused management and improvement of support functions.

🛠️ Arming your support specialists: Provide tools, knowledge bases, and access to resources that empower support specialists to resolve issues independently, minimising developer involvement.

📑 An agreed, documented workflow for issues: Develop a clear, evolving workflow for addressing support issues that can later be formalised in your issue tracking system.

🗺️ A coherent strategy on how support is tackled across the organisation: Define the role of product teams in support and decide whether to dedicate teams, outsource, or set thresholds for issue handling.

🔁 Regular reviews and iteration of support processes: Hold frequent, lightweight reviews of support processes to align, prioritise, and iterate as needed.

Low product quality

Whilst often resulting in customer support overwhelm, low product quality can also:

Erode customer confidence in your product and organisation
Erode the wider organisation’s confidence in product engineering
Elongate development and release cycles
Kill morale
Lower the quality bar more generally

And the five best ways to tackle this?

Clear product principles

Setting the quality bar from a user experience can really help. This may manifest as a broader principle around quality, but it can also be useful to set your stall out from the off in terms of lower level detail. No layout flicker. Standardised, informative error handling. Max page load times. The basics that you might take for granted in some products, but without this, these things can often manifest in support issues down the line.

Automated testing

To be fair, rigorous manual testing - including a well defined and reviewed approach to regression testing - can make a world of difference. But it often slips. And it's prone to error. Automating this is a logical next step, and for me is the gold standard all product teams should strive for.

Continuous integration and continuous delivery (CI/CD)

Baking your automated testing into your CI/CD process maximises the value your automated testing provides, shifting it earlier in your process and reducing the effort required to resolve issues as they’re found at the earliest possible point.

Collaborative software development

This could be a three amigos session at the end when an engineer thinks a user story is ready to be merged in. It could be a three amigos session before development starts in anger. It could be pairing or mobbing. It could be code reviews. Anything that helps to foster that shared understanding, and gets a few more pairs of eyes on new capabilities can really help here.

The Scout Rule

Put simply, leave a place better than you found it. If you spot quality issues whilst working in a certain area of your product or code base, try and address them where possible.

Creaking architecture

There are two schools of thought on this, and over the last few years I’ve veered from the former to toward the latter:

Build for scale from day dot, or
Don’t build for scale initially, and replatform if and when necessary

I think what has swung it for me, is all those who have built from scale since day one have either a) ended up replatforming anyway, or b) have been forced to sink years into strangling out legacy tech to replace it with more modern, more performant components.

Either way, a time will likely come when your tech stack itself becomes the blocker, and someone will utter the word that product folk so often dread: Replatform

But it doesn’t need to be this way! I jotted down a few product/delivery perspectives on replatforming exercises last year, and here are the key takeaways of what you can do to emerge on the other side unscathed:

📣 Be open and transparent about what and why: Clearly communicate the reasons for the lift-and-shift, referencing metrics and scope to ensure everyone understands the need and focus.

⏳ Realistic timelines: Set realistic expectations for timelines, acknowledging that lift-and-shifts can take years, and always have contingency plans in place.

👥 Dedicated teams: Assign dedicated teams to the lift-and-shift, but encourage variety in their work to maintain morale and avoid burnout.

🗣️ Regular comms: Overcommunicate progress to ensure visibility, using simple metrics (e.g., "two out of six") to track and share progress.

🤹 Central coordination: Appoint a central figure or group to coordinate efforts across teams, ensuring alignment and focus.

🔄 Breathing space with third parties: Clarify the commercial deadlines and contingencies with third-party providers to avoid penalties.

🌊 Don't boil the ocean: Avoid the temptation to combine unrelated improvements with the lift-and-shift, and focus solely on the core task.

🎁 Deliver it properly: Use iterative delivery, beta testing, and the strangler pattern to reduce risk and deliver value incrementally.

🎯 Focus on outcome: Even if the goal is maintaining current service levels, define and measure outcomes to keep morale high and maintain focus.

🗺️ Visualise the work to be done: Use story maps or architecture diagrams to provide a clear, one-page view of the transition, showing progress and next steps.

🚫 Visualise the work NOT to be done: Be explicit about what won’t be tackled to avoid confusion and set clear expectations.

🧩 Break the work up into chunks: Deliver the work in small increments to shorten feedback loops, reduce risk, and build confidence.

🍰 Slice into releasable deliverables: Understand the organisation’s landscape to balance disruption with risk minimisation, releasing changes strategically.

🕵️‍♂️ Champion technical discovery: Advocate for technical discovery to explore different options and creatively de-risk the project early on.

🚧 Unblock the team(s): Focus on removing obstacles and supporting the team by clearing the path for their work, especially during technically heavy phases.

📢 Communicate progress: Regularly communicate progress to keep teams, stakeholders, and the wider organisation informed and aligned.

🛡️ Support organisational readiness: Prepare the organisation for changes in user experience, using comms and show-and-tells to ensure smooth adoption.

Lack of automation

There are two main areas where a lack of automation is felt: testing, and pipelines (CI/CD)

As products grow ever more complex, development and release cycles will become lengthier, and the lack of automated testing in particular can chip away at overall product quality. Cognitive load also takes a hit here: manual testing often falls on product or engineering folk in the absence of dedicated QAs, and a flaky pipeline that takes forever often leads to more starting and less finishing.

CI/CD is more of a non-negotiable nowadays, but make sure you factor in the time and discipline required to keep on top of this.

Automated testing you may be able to live without initially, but there comes a time when you need to push the button on this. Start small, with the most commonly used journeys of your product, and grow from there. Pro tip: Don’t go too far with this! I’ve seen organisations tie themselves up in knots with excessive, cumbersome automated tests.

If you have a lot of debt to pay down in this area, consider bringing in automation specialists to give you a boost.

Product and sales misalignment

The relationship between product and sales can make or break a B2B company as it scales. Clear, intentional communication is core to making this work - both at individual contributor (IC), and at leadership level.

There is no one right answer here, but where I’ve seen this balance be the healthiest, I’ve noted these commonalities:

There is a shared understanding of the product value proposition, its target market, and ideal customer profile(s)
Product teams strive to ensure their counterparts in marketing and sales are as aware as they can be of the current and upcoming capabilities of products
Marketing and sales teams actively pull on product teams for input on product capabilities and reviews of sales and marketing materials
Product team members “ride-along” on sales calls
Organisations become strategically selective of customers that they onboard and renew
There is no dogma, and an acceptance, or better still an expectation, that sometimes sales will derail more strategic priorities
Sales teams are not incentivised in a way that undermines broader strategic aims

Those Dreaded Sales-Led Feature Requests from Jason Knight is also well worth a read.

Lack of product data

Without product data, it becomes incredibly difficult to concoct and execute a feasible strategy, and almost impossible to measure your progress towards goals.

The shape of the challenge here can differ. Sometimes it’s a data engineering problem - getting product data out of your production stack and into a dedicated data stack, or flattening and weaponising the data to expose it to analysts. Or it can be the analysis itself.

Your product teams can help move things forward themselves (see "Unlocking your product data" for a guide on how they can do this), but the reality is that you will likely need to invest time and money into building out your data stack, and it’s rare that your “feature” engineering teams will have the skills or the time to do this alongside their “business as usual”.

This often results in dedicated data engineering hires, and as time progresses, a data engineering function. An alternative here may be to get external help for this, bringing in burst capacity from the likes of us, or consciously opting for “data-engineering-as-a-service” from the likes of Assured Insights in Manchester.

Lack of direct user research

As orgs scale, those building products can often get further and further removed from users unless they consciously strive to maintain regular contact. And barriers can appear in the form of dedicated sales teams, stricter regulations, or even dedicated user research functions that become empires in their own right.

When this happens, it leads to worse user outcomes, which in turn leads to worse outcomes for the organisation.

The main thing I'd say here is that any research here is better than none, and anyone can drive it. Start simple and small. If I could give you any grounding at all here, it would be this from Rob Fitzpatrick's excellent "The Mom Test" that I listened to recently:

Talk about their life instead of your idea
Ask about specifics in the past instead of generics or opinions about the future
Talk less and listen more

If you've never done this, you'll be amazed by how much insight you get from following these three simple guard rails.

Lack of people

A team becomes overloaded, so you look to break out that team's responsibilities across two teams. If you fail to properly staff these teams, you’ll end up at a net deficit, given the overheads of cross-team alignment discussed earlier.

So what do you do? In descending order of priority:

Try and move someone into your new team from another internal role

I’ve seen this work wonders in various organisations, none moreso than the BBC where they actively encourage practitioners to transition to other teams to broaden their horizons. The obvious downside here is that you effectively rob Peter to pay Paul, potentially shifting the bottleneck from one place to another.

Recruit full-time employees externally

Some would argue this may be a smarter move than looking to shuffle around internally, just don’t underestimate the cost and energy required to go down this route.

You could do a lot worse than having a rifle through our "Making your first product hire" article.

Bring someone in temporarily

Do you know an independent contractor that could come in and steady the ship, if only temporarily? There are plenty about.

Or could partnering with the likes of Hyperact get you firing on all cylinders?

The latter option worked well for the likes of RiskSmart and thinkmoney.

Lack of skills

Slightly different from purely a lack of people, but the answer may be the same: bringing in additional talent.

There are alternatives here though. Whether it's delivery management you need, or product management, or Golang, you could carve out the time for your people to upskill.

There’s no better way than learning by doing - perhaps with one team leading the charge as a pilot and playing back to the wider community.

If you need a helping hand, Hyperact have provided coaching to the likes of Dstny and Capsule in recent months.

Working groups, or communities of practice can work wonders here as well, bringing a few eager early-adopters together initially and proliferating passion and best practice to the wider org as they hopefully grow over time.

In summary

Scaling challenges are inevitable, and they often stem from multiple interconnected causes. Overcoming them requires deliberate effort - through organisational design, a coherent strategy, and strong alignment across teams. By decentralising decision-making, reducing work-in-progress, and fostering collaboration, you can untangle these issues and address them in isolation. These hurdles, while demanding, are not insurmountable, and this article hopefully provides some tools to help you address them head-on.

Written by Dave Baines

Co-founder, Director

24 Oct 2024