The big and the bold needs catalyst thinking

“My role is that of a catalyst. I try to create an environment in which others make decisions.“
Ricardo Semler, in his book, “Maverick.”

Creating something big and bold that’s never been done before (within a company, if not an industry) seems to scare most people in OSS. I think that this comes about partly because most people in the tech industry seem to be details (or bottom-up) thinkers – if they don’t have (almost) all of the details stitched together then it becomes a massive task of gathering all the pieces before a solution can be proposed (ie it becomes a really hard problem to solve).

But new, big and bold OSS needs top-down thinking. By nature, you don’t have all of the pieces of the puzzle figured out, so you have to start from the top – and break things down piece by piece, digging deeper on each element and discovering along the way. The WBS (Work Breakdown Structure) and mind-map approaches support this top-down approach.

One of the challenges with this approach is that the catalyst must be humble enough to acknowledge that they won’t have all the answers, but will rely on the smarts of other people who have the detailed knowledge.

Over the years, I’ve been able to coax teams of people much, much cleverer than I out of their stalemates and through to implementation using this approach. Whilst I may have facilitated, it was always the team that resolved a vast majority of the challenges. Just a few examples include:

• The creation of a traffic engineering module that had been sold to a customer before being even conceptually architected. The team was almost ready to default on a many-million dollar contract due to the complexity of building a whole new traffic engineering engine but we were able to stitch together a set of existing tools with only a few weeks of effort
• An orchestration engine that had stalled for months because the underlying technology wasn’t at all suited to what the customer needed done. After another month, we had a working version that became saleable as a product to many existing customers around the world
• Before automated discovery was common-place, we had a highly flexible data model that could absorb almost any network technology. However, that flexibility meant we needed a discovery platform that could cater for any known or future technology. After 2-3 intense months, we were able to discover and aggregate circuts that traversed multiple domains, linking feeds from different management systems and building on multiple layers of bearers
• Helping a high-profile, green-fields carrier to go live with operational processes that extended well beyond the reach of our OSS offering, The customer’s big-4 consulting firm and their legion of staff had not come close to building workflows that would allow the customer to go live by a regulator-imposed deadline.
• Unlocking the secret of integrating to a network interface within hours after it had previously consumed 6-8 weeks of interrogation effort

BTW. Having a great adjacency view described in the previous post also helps to understand the top-level pieces and who to engage in the team.