In a small organisation, a difficult customer request may reach the people who can resolve it through a short conversation. Someone knows why the original commitment was made, who maintains the relevant system, and what other work would need to move. Much of the coordination happens without a formal process because the participants already share the necessary context.
As the organisation grows, that conversation becomes harder to reproduce. The customer may belong to another region, the relevant engineers may work across several products, and the person approving the commercial terms may never have met the people supporting them. Decisions that once relied on personal familiarity need a more reliable basis.
Growth does not make strategy inherently unworkable, and there is no universal headcount at which an organisation’s approach must fail. It does change the conditions under which decisions are made. A strategy can remain commercially sound while the way it is communicated, funded, and implemented needs substantial adjustment.
Identify What the Original Approach Relied On
A software provider might build its early customer base by adapting its product closely to each customer’s requirements. A small group can weigh requests together, explain the consequences, and decide which changes belong in the common product. Customers value the responsiveness, and the team learns from direct contact.
Expansion into more markets introduces new conditions. Account teams make commitments at different times, customers use different integrations, and support staff need to understand a larger set of configurations. The original ambition of being responsive can still make sense, but the practical meaning of responsiveness needs examination.
The provider should identify the assumptions behind its earlier success. Did engineers have direct access to every customer? Did the founders personally resolve exceptions? Could the same people design, release, and support a change? Was the cost of maintaining variations small enough to absorb without explicit pricing?
Those assumptions are different from the strategic aim itself. The company may keep its focus on a particular customer group while replacing informal exception handling with a clearer product policy. Alternatively, it may find that the original level of customisation cannot remain profitable at the intended volume. That would require revisiting the offering, the commercial terms, or the growth plan.
This distinction helps avoid two unhelpful responses: assuming the original strategy must be preserved in every detail, or abandoning it whenever coordination becomes difficult. The first task is to establish what has changed and which decisions depended on the old conditions.
Preserve the Reasoning People Need
A larger organisation cannot depend on everyone knowing every discussion. It needs to decide which context people require to make sound local decisions. For the software provider, that includes the customers it intends to serve, the problems it wants to solve, and the kinds of customisation it is prepared to maintain.
A general statement about customer focus leaves too much unresolved. An account team needs examples of requests it can accept, requests that need assessment, and requests outside the current offering. An engineering team needs to understand why a capability matters and whether it is intended for one customer or the wider product.
Written guidance can preserve that reasoning across locations and changes in staff. Its usefulness depends on whether it reflects current decisions and answers questions that arise in the work. A long strategy document that describes the market but leaves commercial exceptions unexplained will not help an account manager decide what to promise.
Communication also needs a route back from the teams applying the guidance. A new region may encounter a common integration requirement that the original product policy never considered. Staff should be able to present that evidence and obtain a decision without interpreting an omission as either permission or prohibition.
This is the practical challenge of preserving context during handoffs. Some interpretation is necessary because local conditions differ. The aim is to give people a common basis for that interpretation and a way to resolve cases the existing guidance does not cover.
Delegate Decisions Within Clear Boundaries
Growth often reveals how many decisions still depend on a few experienced people. A founder may continue to approve unusual contracts, resolve product conflicts, and negotiate delivery dates. The arrangement preserves consistency, but the waiting time becomes part of every team’s work.
Adding approval steps around that same person does little to address the underlying concentration of authority. The organisation needs to establish which decisions can move closer to the work and what conditions should govern them. For example, account teams might be authorised to offer standard configurations within agreed commercial terms, while changes that create ongoing product obligations require a broader review.
The boundary should reflect the consequences of the decision. A reversible change within an agreed budget may be handled locally. A commitment affecting security, contractual obligations, or several products may reasonably need specialist review. Delegation remains compatible with controls when the limits and responsibilities are explicit.
Escalation also needs to work in practice. The requester should know what information to provide, who can decide, and how an unresolved issue affects the customer commitment. If every unfamiliar case returns to the founder, the organisation has transferred tasks without transferring enough authority.
Managers will need support as they take on these decisions. Reviewing a sample of cases can reveal whether the guidance is clear and where judgement differs. That creates an opportunity to improve the decision model before responding with another approval layer. Unclear authority becomes particularly expensive when several teams are waiting on the same answer.
Examine the Dependencies Behind Team Growth
Hiring more people does not necessarily add useful delivery capacity at the same rate. The effect depends partly on whether the additional teams can complete meaningful work or must repeatedly queue for the same specialists, systems, and approvals.
For the software provider, creating separate teams for new markets may appear to support expansion. If all those teams need one integration engineer and a shared release window, their plans still depend on a narrow point of coordination. Recruiting more account managers could increase demand on that constraint without increasing the company’s ability to fulfil commitments.
Map the work from a customer request through assessment, implementation, release, and support. Identify which dependencies represent necessary collaboration and which exist because ownership or interfaces remain unclear. Some work belongs together; other work can be made more independent through a stable service, an agreed contract between systems, or a clearer team responsibility.
In software delivery, DORA’s guidance on loosely coupled teams emphasises the ability to test and deploy without depending on extensive coordination with other teams. That is a useful, specific check on the relationship between technical architecture and team structure. It does not imply that every business function should operate independently or that changing an organisation chart will remove technical dependencies.
A shared capability may remain the right design. In that case, its demand, service expectations, and capacity need to be visible. The provider might invest in a supported integration platform, reduce the number of permitted variations, or reserve specialist capacity for a smaller set of launches. Each option changes a different part of the system and should be assessed accordingly.
Review Growth Through Commitments and Results
Expansion plans need to include the work required to support expansion. Launching another region may require customer documentation, support coverage, billing changes, access arrangements, and training. Those activities draw on existing teams even when the regional budget mainly shows new sales and delivery roles.
Reviewing only each department’s headcount can miss this combined demand. The provider needs to examine the commitments across the customer journey and establish whether shared teams can fulfil them. A programme that is feasible in isolation may become unrealistic when several launches rely on the same people at the same time.
Sequence matters. The company may need to standardise an integration process before opening several markets, or limit the initial offering while support capability develops. This should be reflected in customer promises and revenue expectations. Treating preparation as optional work while keeping the full expansion target creates a plan that assumes capacity it has not secured.
The review should also distinguish coordination problems from a change in the market proposition. If customers will only buy with expensive customisation, better internal communication may help fulfil the work but will not resolve the economics. If the standard offering sells well but waits months for implementation, the primary problem may be delivery capacity. These findings lead to different decisions.
Useful evidence includes the time taken to resolve exceptions, the number of commitments awaiting shared capacity, implementation effort by customer type, and whether support can maintain the delivered service. These measures should be interpreted alongside customer outcomes and the costs of serving them. A faster local process is less useful if it transfers unresolved work downstream.
The organisation does not need to recreate the personal familiarity of its earliest days. It needs a dependable way for people to understand the direction, make decisions within their remit, and coordinate the work that crosses boundaries. Growth can bring valuable specialisation and resources; realising those benefits requires adapting the arrangements through which the strategy is carried out.
The test is practical. Can a new account team make a promise the delivery teams understand and can support? Can an unfamiliar request receive a timely decision? Can leadership see when growth is consuming capabilities faster than they are being built? Those questions provide a more useful basis for adaptation than assuming a particular company size makes strategic coherence impossible.
