In Part 5 I focused on the list of activities and behaviors needed to drive the transformation to cloud internally. It was a laundry list of items to consider when setting on this journey. In the next few sections, I’ll be diving deeper into that list, and not necessarily in the order they were listed. Let’s start with the education needed: Internally, with customers, suppliers, resellers, and investors. The focus again is on non-cloud companies transforming to cloud.
- Initially it is likely the breadth and depth of change won’t be fully understood or will rather be underestimated. It may be focused on the technical aspects alone of moving to new architecture, development methods, software stacks and the likes. It will likely also cover the training needed for pre-sales, integration, and support organizations.
- What may be underestimated are the changes needed in the incumbent way of thinking:
- The language of finance and financial metrics, the eyes of the business, will need to change. From bulky perpetual sales, to MRR and ARR.
- “Gut” feelings and confidence in financial modeling will be low with the new ARR/MRR models vs. the old familiar perpetual sales models
- New MRR products and businesses may appear far less appealing than legacy perpetual ones as there will be low confidence in the new less familiar businesses. Not only are they using new technology, they are also being reporting in less familiar ways making many in the organization potentially uneasy
- Investors, board members, and the street (if public) will need to be educated on new measurement. Questions must be asked, and expectation set as to “What does success mean”? Does forecasting, for example, $3M in MRR for the next quarter equal, be worse, or be better, than $35M of perpetual revenue in the next quarter
- If the company is an innovator in its move to Cloud, vs its peers, it will be met with a mix of enthusiasm from long term investors and in some cases skepticism from short term investors who will need whole quarters or years of financial results to be convinced the move to cloud is the right one
Internal Resistance from Legacy organizations
- If you are a company that has had all It’s past success from hardware products or integrated systems (hardware + software) in shrink wrapped products, the leaders of those organizations will be prominent, and their opinions likely carry a lot of weight in the organization
- These organizations will be used to headcount growth, continued investment, and exciting career paths for the employees
- Going forward, these organizations will be tasked to support the transformation to cloud, supporting products whose roadmaps have ended in the old architecture and move to legacy
- They may be asked to reduce hardware group sizes, change existing plans
- There may be debates, almost of a religious nature, as to what is achievable in SW only vs. HW with much disbelief from Hardware centric engineering teams. Old-timer tech teams may be at odds with born-in-the-cloud newcomers as to architectures
- The career attractiveness of a future dominant in support of legacy products vs. the company’s leading products will not be appealing to many who were used to being the center of technical attention
- There are solutions and aids to helping managing this, like outsourcing to low-cost IT firms (if you’d like to learn more on this contact me directly)
- Engineering can be structured into workload buckets that protect the new and innovative. For example Legacy support can be limited to 30% of engineering time. Perhaps not initially, but starting year 2-3 of transformation. This may require organizational restructuring to prevent work creep as structural constructs tend to be more defendable against legacy support creep than a matrixed structure with soft project tracking time
- Partners, several not as technologically astute as the vendor company, will need to go through the same process of understanding how they will need to change
- Education of sales, pre-sales, support. New contracts, new reporting, accounting, forecasting and more. It is the responsibility of the company (vendor) to prepare its partners, and well in advance of the change. It should create programs, and staff to support partners, and regularly check on where partners are in their ability to sell the new cloud offerings. The biggest mistake would be to assume this will be smooth or that even all partners will be able to adapt to the new models
- Assessing partner readiness in advance of the partner communication is an even better approach
- Customer education along the receiving end of services from the company should be planned, programmed, and tracked. They must be prepared for new consumption methods (financially), for new support processes, new deployment, and installation schema and more
Each on the domains above deserves an even deeper examination but for the sake of brevity will keep it as this level for now. As one can see – the more one plans, assesses in advance, tracks, communicates, and rinses and repeats the above steps, the more successful cloud transformation will be!
In the next parts I will be continuing the deep dive from my experience in each.
*** As usual, feel free to contact me at [email protected]?if you’re looking to engage with me on a consulting/advisory basis as an operating partner, fractional CXO and work on cloudification, transformation, turnaround, growth, product strategy, VC & PE advisory, or start-up mentoring. More here ***
?Part 5 - TheCloudGuy Series on Transforming your Company into Cloud and SaaS
Driving Products and Customer Success with a consistent track record of delivering results
2 年That is really insightful, thanks for sharing Lior Netzer