Part 8 - Creating a Transformation Plan - TheCloudGuy Series on Transforming your Company into Cloud and SaaS

In Part 7 I focused on the education needed, primarily to investors, analysts and your customers and their shareholders as you transform to Cloud. In this part I’ll focus on how to create a transformation plan for your product, engineering, and support organizations. The focus again is on non-cloud companies transforming to cloud.

Here’s your situation: You’ve identified the scope of your product(s) in their cloud form. You’ve validated it with your North Star customers that the rest of the market follows. The technology and industry trends clearly support the direction you are heading. You think you know how long in the future the majority of consumption will be Cloud vs On-Prem but you can’t really know until you get into your early majority segment (see https://strategiesforinfluence.com/crossing-the-chasm-geoffrey-moore/)

?You need to start. You should have started yesterday, but you also need to live within your operational budget which hasn’t miraculously grown by leaps and bounds (if it has, you probably don’t need to read the below).

?Customer demands haven’t gone away. There are generations and generations of old product in the on-prem install base that you still need to support. You already feel understaffed and now you are about to take on a big new challenge requiring extra resources you likely don't have.

?One Recipe out of this situation, and one I have implemented, is as follows:

?A) Win the hearts and minds of your engineering leaders. Not just the head of the organization but mainly level 2 and level 3 leaders. Any leader that runs an organization of 30 or more people (if not less) should be bought it. Do this via communication, workshops, vision and mission alignment. Involve them in finding a solution that most fits your organization. You are about to upheave their well thought out and well-oiled organization. They need to be part of your solution.

B) Let’s assume that via Step A you have buy-in to change roles and re-org based on three categories: future, current, and legacy. In this scenario you should organize in groups with clearly defined roles, and protects those boundaries against “leakage” into external resources. For example, organize your Product and Engineering such that:

?In Phase 1: (6-12 months)

30% work on the cloud platform – the common core of your cloud offering

30% on customizations and short term wins – adapting the new offering to specific customer needs

40% work on Legacy (the existing now, that will soon become legacy)

In Phase 2 (the following 6-12 months)

50% work on the cloud platform – the common core of your cloud offering

30% on customizations and short term wins – adapting the new offering to specific customer needs

20% work on Legacy (the existing now, that will soon become legacy)

This is much easier said than done and will depend heavily on how your engineering is organized. Is it highly matrixed where most teams support most products? Is it highly siloed where there is a team per product? Mostly likely you are a blend of both leaning heavier in one direction or another.

C) Set deadlines, communicate with your whole product & engineering organization. Explain to them why this is the right thing so they all have a brought future with the company, and start executing.

D) Be disciplined and brutal in protecting the structure laid out in (B). Every task needs to fit within the resources of it’s group. Legacy work only has the number of people on that team. Account managers and sales people will understand why your are doing this, but will still need to serve their customers, and may kick and scream and escalate incidents that are suddenly short staffed to address vs. the recent past. You must stick to your ground. Exceptions can happen but they have to be real exceptions. Perhaps each exception that in the past needed Director level approval will now need VP, SVP or even CEO approval. Do the same with short term win needs and future needs. If anything, go bigger on those vs. the legacy

E) repeat the same steps with your other organizations: Support, Operations, Marketing and more. With each one repeat steps A-D and find out best structure

F) Revisit your plan frequently and make adjustments. Have a formal checkpoint at least once every 6 weeks. Not too frequent as it will seem like you are indecisive, but also not too seldom to miss out on flaws.

G1) Keep communicating whey you are doing and why you are doing it like a broken record. To your management, board, customers and more. They may not be happy with less support on legacy but if they understand why they will cut you some slack. You are promising them all a better and more current future and a reason to stay with you.

G2) Set expectations and communicate what the future looks like to everyone, in their eyes, and in their function. Don’t assume they get it. The more detailed you are , the more success you will have.

Mostly don't fear the change. You most likely have no choice, so you may as well get started!

In the next sections will deep dive into cloud support , customer success, community support , developer community, hybrid cloud and cloud security topics/

*** 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 ***