There has been a successful pilot. Management wants pace. The decision is made: roll out to the rest of the organization, other teams, other departments. What worked in one corner must now work everywhere.
That does not always go well. Not because the technology suddenly responds differently, but because the environment in which it must function is set up differently everywhere. The team where the pilot succeeded happened to have an IT infrastructure that could handle what was asked, data management that was in order, and an organizational structure in which someone took responsibility. Elsewhere in the organization, one or more of those things are different. The result: the same effort delivers something in one place and nothing in another, or worse, extra work to fix errors.
Scaling up feels like the next step because the pilot proved something. There is an outcome, there is enthusiasm, there is pressure to increase returns. Once someone has made something work, they don't want to keep it limited to one team. Moreover, scaling up is visible: more users, more teams, more process lines that pick up the new way of working. That feels like progress, even when the fundamental dimensions — organization, IT infrastructure, data management — are not yet everywhere at the level at which the dimension that depends on them can actually run.
The order in which this works is not optional. If the fundamental layer is not in place, the dependent layer has nothing to build on. That is not a matter of preference or of taking more time; it is the way the dimensions support each other. Scaling up ignores that order and expects that repeating a way of working is sufficient, even without the groundwork that happened to be present the first time.
A number of signals recur often. Teams that adopt the new way of working report varying results, and no one can properly explain why it works for one team and not for another. There are calls for more training or more communication, while the problem lies elsewhere: in systems that don't connect to each other, in data that is not of the same quality, in a structure in which no one owns the result across team boundaries.
Also recognizable is the situation in which technology is rolled out over a structure that has not itself changed: the new way of working is made technically available, but the roles, responsibilities and decision lines have remained the same as before the pilot. Comparable is the pattern in which a pilot functions well in its own corner but does not connect to the rest of the organization: the scale-up copies the way of working, not the conditions under which that way of working came about.
A third signal is less visible but just as decisive: two enthusiasts pull the cart and no one else feels responsible. As long as the initiative depends on a few people who happen to be motivated, there is no organizational foundation to scale up on — there is only enthusiasm that does not multiply once the team grows larger.
Anyone who recognizes these signals would do well to ask whether the divergence between teams is a consequence of execution, or of a difference in readiness that was already present long before scaling up began. That distinction is exactly what hybridresourcing's maturity assessment looks at: not a single score for the whole organization, but five levels across seven dimensions, measured by having multiple people score separately so that the divergence between their answers becomes visible. That divergence often tells more than the average: if the CEO's assessment differs fundamentally from the CIO's, that is part of the explanation for why scaling up succeeds in one place and not in another. What a CEO sees in this assessment about their own organization and what a COO recognizes in it from daily execution rarely produce the same picture, and that difference is exactly what the assessment is built on.
This page is about the question of whether the organization can carry AI: is the structure, the infrastructure, the data management at a level at which scaling up makes sense. That is a different question from which part of the work itself is suitable to hand over to AI. The latter question is answered by the work scan from FTE TO AI: it calculates per task which part of the work can be taken over by AI, independent of whether the organization is already ready for it. Both questions belong together, but the order is not optional — knowing what is transferable has little value as long as it is not established whether the foundation can carry that transfer.
hybridresourcing's maturity assessment is still being built. Anyone who wants to use the assessment as soon as it becomes available can sign up for the waiting list.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.