Do you work in a large organisation? Have you also worked in smaller organisations?
Where have you felt more efficient?
I’ve been lucky enough to work on some massive OSS transformations for large T1 telcos. But I’ve always noticed the inefficiency of working on these projects when embedded inside the bureaucracy of the beast. With all of the documentation, sign-offs, meetings, politics, gaining consensus, budget allocations, etc it can sometimes feel so inefficient. On some past projects, I’ve felt I can accomplish more in a day outside than a week or more inside the beast.
This makes sense when applying the fundamental law of physics F = M x a to OSS projects. In other words, the greater the mass (of the organisation), the more force must be applied to reach a given acceleration (ie to effect a change).
It’s one of the reasons I love working within a small entity (Passionate About OSS), but into big entities (the big telcos and utilities). It’s also why I strongly believe that the big entities need to better leverage smaller working groups to facilitate big OSS change.
Big business (eg telco) tends to prefer dealing with big business (eg vendors, consultants, solution integrators). That doesn’t alleviate the F=ma problem much though. Big business could develop more efficient ways (see below) to utilise the gig economy to get activities done in lower inertia environments.
Not just OSS transformation, but any project where the size of the culture and technology stack are prohibitive.
Here are a few ways you can use to bring a start-up’s efficiency to a big OSS transformation:
- Agile methodologies – If done well, Agile can be great at breaking transformations down into smaller, more manageable pieces / teams. The art is in designing small autonomous teams / responsibilities and breakdown of work to minimise dependencies (see also the Chessboard Analogy)
- Partnerships – Using smaller, external partners to deliver outcomes (eg product builds or service offerings) that can be absorbed into the big organisation. There are varying levels of absorption here – from an external, “clip-the-ticket” offering to offerings that are fully absorbed into the large entity’s OSS/BSS stack
- Consultancies – Similar to partnerships, but using smaller teams to implement professional services
- Spin-out / spin-in teams – Separating small teams of experts out from the bureaucracy of the large organisation so that they can achieve rapid progress
- Smart contracts / RFPs – I love the potential for smart contracts to automate the offer of small chunks of work to trusted partners to bid upon and then deliver upon. This is especially suited to utilising the gig economy
- Externalised Proofs of Concept (PoC) – One of the big challenges in implementing for large organisations is all of the safety checks that slow progress. Many, such as security and privacy mechanisms, are completely justified for a production network. But when a concept needs to be proved, such as user journeys, product integrations, sand-pit environments, etc, then cloud-based PoCs can be brilliant
- Alternate brands – Have you also noticed that some of the tier-1 telcos have been spinning out low-cost and/or niche brands with much leaner OSS/BSS stacks, offerings and related culture lately? It’s a clever business model on many levels. Combined with the strangler fig transformation approach, this might just represent a pathway for the big brand to shed many of their OSS/BSS legacy constraints
Can you think of other models that I’ve missed?
The key to these strategies is not so much the carve-out, the process of getting small teams to do tasks efficiently, but the absorb-in process. For example, how to absorb a cloud-based PoC back into the PROD network, where all safety checks (eg security, privacy, operations acceptance, etc) still need to be performed. More on that in tomorrow’s post.Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email