Software Eats the World

This blog re-posted with permission. This blog originally appeared here:  https://cloud.vmware.com/community/2018/03/13/ask-alex-part-6-software-eats-world/

Alex Jauch is a Director of Product Management for VMware Cloud on AWS. In this six-part series, he answers your burning questions about enterprise public cloud.

In part six, he’ll answer the question: “My company isn’t really interested in moving faster or digital transformation, is that a problem?”

Yes.

If there is one thing that we know for sure about cloud it’s that this paradigm shift is all-encompassing and permanent. Businesses today are extremely likely to be disrupted by software companies and this disruption should be viewed as an existential threat, no matter what business you are in. I cannot overstate how critical this is to your company.

While you may not like the term “digital transformation” or the other buzzwords running around the industry, you should be aware of the facts.

As Mary Meeker pointed out in 2017, at least 65% of the US GDP is under threat of major disruption from software (housing, transportation, and food). This is the LOW END of the scope here. It is easy to find ways that most of the rest of GDP is being targeted.

A more recent report by McKinsey posted on HBR draws an even more dire conclusion:

Technological innovations have radically transformed the business landscape in many ways over the last two centuries, from the introduction of steam power to the market conquest of radial-ply tires. Research by McKinsey & Company and the McKinsey Global Institute shows that digitization is having the same radical impact. In particular, our research shows how digitization can significantly hurt incumbent firms in many industries — depleting as much as half the revenue growth and one-third of earnings before interest and taxes (EBIT) growth of companies that neglect to embrace digital innovations.

To repeat, your future revenue growth is curtailed by 50% by failing to make this change. More alarmingly, they go on to point out that only 20% of the 1,650 firms they surveyed currently have a digital transformation strategy. Taken together, these statements are quite alarming. In short, most of you are going to suffer significant financial penalties because you don’t have a strategy around digital transformation. In our terms, this means that one of the things you probably don’t have is a focus on “velocity-driven IT” which is a big contributor to these types of digital transformation strategy.

Many people assume that we are talking about little guys taking on big guys, and that is definitely happening (AirBnB vs. the hotel industry for example) but we are also seeing entrenched incumbents taking these lessons to heart and driving innovations within their own customer base. See Walmart experimenting with self-checkout for example. While some of these initiatives will fail, the point is that innovation from known competitors will increase in velocity if your competitors take this path. Even if you are not directly under threat from a software company, your direct competitor can take strategies from the software business and act like one. If they can delight their customers by innovating with software, you could be in trouble.

In the end, the question is this: As an IT organization, what are you doing to contribute to your firm’s long-term competitive prospects?

If you don’t know the answer to this question, you may want to reach out to your business leaders to figure out how you can transform your IT organization. I would argue that this is the single most important thing that IT leadership can do today.

I will leave you with food for thought: When Marc Andreessen said: “Software is Eating the World.” He wasn’t talking about hardware companies or high tech companies. He was talking about bookstores and video rental companies.

Most likely, he will be talking about your business in the near future.

There is no Cloud

This blog re-posted with permission.  This blog originally appeared here:  https://cloud.vmware.com/community/2018/03/06/ask-alex-part-5-no-cloud/

Alex Jauch is a Director of Product Management for VMware Cloud on AWS. In this six-part series, he answers your burning questions about enterprise public cloud.

In part five, he’ll answer the question: “What organizational changes should I make to prepare for the cloud era?”

As we discussed in our previous post, the primary difference between cloud and traditional IT is a fundamental shift in business model.

Or to put it another way, there is no cloud, there is just someone else’s data center.

The reality is that the center of gravity for enterprise IT has swung back and forth several times over the past 30 years. We have already seen multiple shifts of this type and thus, it is possible to make predictions about how this will evolve in the future.

Looking at the history of enterprise IT, we see several paradigm shifts from things like mainframes to minicomputers and then later distributed computing. During these shifts, vendors have been disrupted and overall IT operating practices have shifted radically.

However, if you look closely, you will see a distinct pattern emerge. This is the shift in budget from central IT to the operating units and back again. This has happened several times. Normally, a shift in budget to operating units is made to allow them to move more freely and to push decision making down closer to the business owner. The theory here is that things will happen faster and better decisions will get made.

Over time this inevitably results in duplication and unnecessary spending. This, in turn, leads to centralization of budgets to contain costs. This centralization tends to lead to cost controls that ultimately lead to less freedom of choice and usually results in less innovation within the organization.

If we concentrate on the difference between velocity driven IT decisions vs. cost driven IT decisions, the cloud transition becomes easier to conceptualize and manage. In this case, the decision is not cloud vs. on-prem, the decision is cost optimized vs. velocity optimized. You may still wind up on the same platform, but the reason why you made the choice is different.

In this context then, the question is a little different. The question now becomes:

“How do I optimize my IT organization for velocity-based IT decisions?”

And

“How do I optimize my IT organization for cost-driven IT decisions?”

These two questions have very different answers.

For most IT organizations, the idea of managing a stable infrastructure with a focus on ROI is already something you know how to do. Standardization, change management, architecture review, all of these processes are designed to manage cost and risk within your organization.

On the other hand, most IT organizations don’t have a strong background in velocity driven decision making. The implications of velocity driven decision making are that you may choose to accept a higher cost or take on additional technical risk in order to increase velocity.

The other aspect of this is that when we talk about velocity in the cloud sense, we are not simply talking about doing things faster. What we really mean is doing things MORE OFTEN. That is to say, rapid short cycles are preferred over infrequent larger cycles. The reason for this is the uncertainty inherent in velocity driven IT. Since you don’t know if the decision you are making is correct, don’t commit to it for a long period of time. Cycle very rapidly, find out if that’s the right thing and be ready to change as needed.

Thankfully, the software industry has done a great job of learning how to make velocity driven technology systems work. The entire concept of agile, scrum and other related systems comes from this notion of velocity requiring rapid iterations in the field of software development.

There are many, many variations on the theme, but there are some common threads here:

• Focus on customer success. Build your backlog with customer stories, prioritize those stories, execute against that backlog in priority order.
• Rapid iterations. Take projects and break them down into very small iterations. Two weeks is ideal. Try to ship every day.
• Test. Once you have a story that works, test that story with your customers. You can actually do this internally much easier than externally because your customers are right there inside the company.
• Make data-driven decisions. Measure everything. The only way you know what to do is if you have data, if you don’t measure, you won’t have data. How do you know if your customers are happy? You ask them.
• Small teams. Scaling agile up is hard. Most software companies who do this well, focus on enabling smaller teams with tools to help them execute. Amazon’s famous “two pizza rule” is a great example of this.
• Re-use. Whether you’re talking about GitHub or SaaS, great software teams steal… ahem, they “re-use” existing code, services and ideas. You need to do the same.
• In summary, you can best prepare your organization for the cloud era by focusing on velocity driven IT and the principles that drive great software teams to higher velocity.

Building Consultants

This blog is re-posted with permission.  It originally appeared here:  https://cloud.vmware.com/community/2018/02/27/ask-alex-part-4-building-consultants/

lex Jauch is a Director of Product Management for VMware Cloud on AWS. In this six-part series, he answers your burning questions about enterprise public cloud.

In part four, he’ll answer the question: “What new skills should my IT organization focus on to prepare for cloud?”

As we discussed in our previous post, the primary difference between cloud and traditional IT is a fundamental shift in business model.

Yes, it is true that new technical skills are required. However, what you will find is that introducing a new technical skill or a new tool into your IT organization is relatively simple to do. Learning new technologies is something you get good at if you want to be in this business.

However, what is not simple is changing soft skills, processes, and ways of doing business. Introducing this type of change into an organization is very difficult.

Because of this, I firmly believe that the introduction of consultative skills into your organization may be the single most important change you can make to prepare your organization for the cloud era.

If you look back on the history of enterprise IT, there has been a steady shift away from low-level technical tasks towards higher level tasks. In the early era of IT, it was not uncommon for organizations to build custom operating systems or database systems for their mainframes. Commercial software was simply not flexible enough to represent all the complex business logic organizations had.

Later, standardized commercial operating systems such as Unix made this unnecessary. Moving forward, commercial databases came along and nobody wasted time making their own database. Similarly, SaaS is moving many traditional workloads like email out of the enterprise data center. This trend is continuing and may ultimately culminate in very few organizations running their own data centers over time. While the jury is still out on the ultimate fate of public cloud within an enterprise, there is no doubt that the trend of moving IT up the stack will continue.

If you combine this trend with the fundamental democratization of IT that cloud brings, it’s clear that traditional command and control based IT organizations will struggle in the cloud era. Because cloud assumes a business model where end users can have whatever they want as long as they’re willing to pay for it, there is no way to use traditional IT governance structures such as Architectural Review Boards or approval chain restrictions. In the cloud era, whoever holds the budget wins. While IT could respond by trying to remove budget from operational departments, this strategy seems shortsighted.

A more forward-looking strategy would be to partner with operational business units and support their business goals by providing guidance, advice, and tooling that helps them maximize their IT spend. By definition, this is a consultative activity rather than a pure engineering activity.

The drive for enterprises to increase IT velocity will inevitably result in fewer IT controls and a highly dispersed IT budget. By pushing IT budget down into operational groups, decisions can be made faster and business goals can be met quicker. The push for higher velocity is a direct response to the level to which enterprises are being disrupted by software companies. With many sectors of the US economy being disrupted by software companies, the drive for ever-higher velocity seems inevitable.

To summarize, enterprise IT is facing a “perfect storm” of external forces that will cause massive disruption in the way IT works:

• – Movement “up the stack” due to SaaS and other cloud technologies.
• – Business shifting to faster velocity strategies results in budget shifts to operational units.
• – Democratization allowing smaller business units to be completely self-sufficient.
• – Technical maturity making core technologies easier to use.

These factors together mean that IT organizations that focus on customer intimacy by developing consultative skills and adopting customer friendly policies will be more successful in the cloud era, than those IT organizations who focus on engineering execution and command and control IT governance policies.

Thus, it is the consulting and customer success skill sets that are most likely to improve your IT organization in the cloud era.

IT Benefits Management

This blog is re-posted with permission.  The original post appeared here:  https://cloud.vmware.com/community/2018/02/20/ask-alex-part-3-benefits-management/

Alex Jauch is a Director of Product Management for VMware Cloud on AWS. In this six-part series, he answers your burning questions about enterprise public cloud.

In part three, he’ll answer the question: “How do I ensure I am making the right IT investments?”

There is a huge potential for IT organizations to fundamentally transform their businesses through the use of cloud business models and architectures. While we see examples of business transformation almost every day, it is rare to see IT organizations leading this change. As we have discussed, I have my theories about this. As I have stated previously, I feel that this is fundamentally an organizational change management problem. IT organizations who attempt to retain traditional organizational structures and processes struggle to implement successful transformations. One aspect of this problem is sometimes referred to as the “bottom line” dilemma. If an IT organization is considered a cost center, it is very difficult for that organization to create the amount of change required to add value. If you are not adding value, you are a cost center by definition. It’s a quandary.

Let’s start with the concept of value. If you want to create value in any organization, you must introduce change. Change is by definition a value precursor. Not all change creates value, but all value creation requires change. Think about something simple like jewelry. If I give you a lump of gold, does that lump have value? Yep. Did I add any value by giving you the lump? Nope. What if I changed the lump into a ring? Ah, I have introduced physical change to the gold. This may have value to you, unless the ring is really ugly. Then you’d probably rather just have the gold. See where this is headed?

You would think that IT organizations are temples to change. You would think that change is in their lifeblood. They thrive on change. Nope. It turns out that this is not true. People are people. Each one has its own level of acceptance for change. Organizations that pride themselves on technical excellence usually resist change.

Why?

Because if you do something, again and again, you get really good at it, you become an expert. Doing something new means the risk of making mistakes and finding out that you are not perfect and do not know everything. There is also an implication that if the new way is better, you must have failed when you started doing it the old way. When I was first starting out at Microsoft Services, a very senior guy in the group asked me a question that I could not answer: “How do you know what you don’t know?” Needless to say, I was pretty put off by this question. It seemed pointless. By definition, you cannot know what you DON’T know; only what you DO KNOW.

Over the years, I came to understand the question and the very important lesson behind it. Being able to say “I don’t know” is a huge skillset in the technology business. When I say “I KNOW” that means I’m sure. If I’m not sure I say “I DON’T KNOW.” My mentor’s question is about understanding and respecting your own limits. For example, when interviewing technical people, my intent is to always ask more and more specific technical questions until the answer is “I DON’T KNOW.” In my opinion, the limit of their knowledge and the ability to understand that they have just crossed that line is hugely important. It’s fascinating how many people will simply keep answering questions and fudging the answers in an attempt to impress.

This is an artifact of what I call the “expert syndrome.” These people are experts. They enjoy being experts. Knowing everything and being able to answer every question is part of their internal mythology. If you are suffering from expert syndrome, you will resist change. This is because any new way of doing things means you are instantly degraded from “expert” to “learner.” This causes you to resist change. Not super healthy for the organization.

This is also a proof point for the customer-centric IT organization. If the business really needs a service that IT cannot provide internally, why wouldn’t they help the business acquire this function from the cloud? This would be the customer-centric thing to do. However, this is not what traditional IT organizations do. Instead, there are policies created to prevent this type of activity. Standards are created. Architectural boards of review are convened. This allows IT to retain control but is not the customer-centric approach. If your job is to protect the business from itself, then this is what you need to do. It depends on your worldview. However, the purpose of this blog is not to debate corporate policy. I bring up these issues to help you understand how incredibly difficult it can be to change the culture of a large organization.

So, if change is good (sometimes) how do we evaluate “good” change and compare that to “bad” change? One way that I really like is to use a technique called “benefits management” developed by Dr. Peter Weil at MIT Sloan. I used to teach a two-day class on this topic, but the short version is that in order to have “benefit”, an IT activity must have underlying business metrics and those metrics must have a business owner. For example, back in the old days, it was common to claim that PCs “increased worker productivity.” OK, great. How do I measure that? Either I produce x more widgets or I reduce expenses (which in IT usually means reducing headcount). That’s it. You cannot say that task x takes 10 fewer seconds and is performed 10,000 times a day, therefore, you have saved 100,000 seconds a day. Saving 100,000 seconds is entirely theoretical until it is expressed into an actual benefit like reducing labor costs or increasing production. This is why IT organizations so rarely have this discussion. It’s hard.

This is especially true when discussing traditional IT benefits like saving time. This implies that the organization reduces headcount which nobody wants to talk about. If you have the luxury of a quickly growing company, this benefit can be expressed in terms of avoided new headcount, but not everyone has the benefit of a large, growing business that’s constantly hiring. No, it’s much more fun to talk about creating top-line revenue: increasing production, exploring new markets, increasing customer satisfaction. Those are always great IT projects.

How do we use this principle to help us align our IT spending? One way is to think about the “benefits” that you think the platform or system will bring to the organization. Things like “increased agility” or “reduced downtime” or “reduced IT labor costs.” Make a list. Hopefully, it’s a super long list. Then you need to categorize these into top-line items (increased agility) and bottom-line items (reduced IT costs). For each item, you need to identify exactly which business owner (or their representative) will benefit within the organization (VP of Sales, COO, VP of Product Development) and figure out exactly how much this will help their organization and what metrics you can apply. Once you have your proposed metrics, you need to go to the business owner of that activity and get them to agree to your metric. For example, the VP of Sales may not be super happy that you’re asking them to commit to an additional $1M of quota because you want to deploy a new sales productivity application. See how this gets complicated? You cannot claim a benefit unless those you claim to benefit agree. That may not always happen. As I said, you’re hoping for a super long list. This lack of visibility and support for IT business improvement is at the heart of failed projects. IT says that things are better but the business either disagrees or simply doesn’t care. Neither of these scenarios is good.

In many cases, this technique will radically change IT’s implementation priorities. The organizations that want IT services come up in priority. Those who are unhappy or uncaring drop down. Remember what I said about running a business? You need to provide a service that your customer wants. Your customers will tell you if you are doing the right thing or not. It is a similar exercise when you use benefits management to ensure that IT is actually creating value for the organization. This is true even if you choose not to do chargeback and no money ever changes hands.

If you know which IT activities are actively producing benefits for your organization, you know where to focus your attention. Those activities which do not directly produce benefits may be areas where you can economize or outsource. Beware, rice bowls will be broken. This is not a fun or painless process and most IT organizations simply give up. However, this type of introspection is vital if you wish to transform your organization for the cloud era.

Creating a Customer Centric Organization

Reprinted with Permission.  This blog post originally appeared here:  https://cloud.vmware.com/community/2018/02/06/ask-alex-part-2-creating-customer-centric-organization/

Alex Jauch is a Director of Product Management for VMware Cloud on AWS. In this six-part series, he answers your burning questions about enterprise public cloud.

In part two, he’ll answer the question: “How do I make my internal customers happy?”

As we have discussed in past blog posts, it is the business model transition from traditional IT to the cloud that is the most difficult part of our journey to the cloud. If we are to become true service providers to our internal customers, we must understand our customers in a way that we have never understood them before. In the end, it is the customer-centric IT organization that will thrive in the cloud era.

Our first question is; who are our customers?

For many IT infrastructure programs, the target customer is the business unit IT administrator. However, the ultimate power of the pocketbook may not reside there. Just like toys are marketed to parents as much as to children, the actual consumer of the cloud infrastructure will most likely not be the business unit IT folks, but rather their end customer within the business. This implies that we have a very indirect value proposition, which is always tricky to pull off. Intel has done a great job of this over the years with their “Intel inside” program. Others haven’t done so well. You didn’t think you’d be planning marketing campaigns when you became an IT person? Well, think again.

SUGGESTION: Your customer is anyone in the company directly involved in making money for the company. Full stop.

Once you understand who exactly you’re selling TO, you need to understand WHAT it is you are trying to sell them. Understanding what you’re selling can be trickier than it seems. This is the difference between wholesale and retail. In the wholesale business, you sell to professionals. In the IT world, when I sell a SAN, or a Private Cloud to a well-run IT shop, we really focus on the bits and bytes. How does it work and how much will it cost. On the other hand, if you are selling to a business leader or an end user, these things are less important. Consumer electronics firms like Apple understand this. Apple products do not focus on the HOW but rather the WHAT. Steve Jobs was famous for saying that Apple products are “magical” and for being very short on details. This can frustrate a professional engineer but is exactly right for a consumer audience.

The reality is that retail customers don’t buy features or products. They buy solutions. If I have a business pain, how do I make that go away? For cloud, the selling proposition usually goes like this: “If you deploy our cloud solution, you will be able to help your internal customers deploy applications and solutions faster at a lower cost point than traditional solutions.” Sound familiar? However, the goal of the IT organization is not to sell their internal private cloud product to other IT people. Usually, the key audience is internal business users or perhaps business unit IT leadership. Those folks must sign off on the budget you are hoping to capture. Even if you are not doing charge-back you need to act as if you are. In the end, budget will need to be procured. Nothing simplifies the budget process like other departments screaming for your services, I can assure you.

SUGGESTION: You are selling business agility, safety, and reduced cost. Something like this: “We enable your business.”

And the next question: What are the typical objections that your customers will have?

Whenever you are selling something, you need to provide value. However, you need to accept that you have competitors. Your customers can go elsewhere. You need to understand that and understand why and how those competitive decisions are made. In the old days, you could simply declare something to be non-standard and the business couldn’t do it. We were the gatekeepers and that was that. I think that era is pretty much over. If a business unit wants to do something bad enough, they’re going to do it. Only a very strong CIO will prevent that. Personally, I don’t subscribe to that type of IT policy. You should be able to win internally 99% of the time without resorting to heavy-handed tactics like that.

You have home field advantage; you should understand their business far better than any outside agency. You have their best interests at heart with no question about motives or long term goals. You don’t have to make a profit. In the consulting business, we referred to this position as a “trusted advisor” state. We always sought to become the customer’s “trusted advisor.” It is the same in IT. Your goal is to be the trusted advisor, helping them achieve their business goals. To do this, you must understand what they like about your service, but probably more importantly, understand what they dislike. I am always interested in customer feedback, but I spend even more time on feedback from someone who DIDN’T choose my solution. What didn’t they like about it? What did they like about my competitor? What can I realistically do differently?

Here’s a quick test you can take in the privacy of your office or cube. Take a look at the list below and see which statements most closely describe your organization: the ones on the left or the ones on the right.

If you have more than four check marks on the left, you may want to consider your organizational focus prior to starting any cloud initiative. It will be difficult to deliver a customer-centric initiative like cloud without a customer-centric IT organization to back it up.

It's not them, it's you

This blog is re-posted with permission.  It originally appeared here:  https://cloud.vmware.com/community/2018/01/23/ask-alex-part-1/

It is part of a multi-part series on public cloud strategy for enterprises. 

In part one, he’ll answer the question: “My internal developers want to move to public cloud. What is it about public cloud that’s so great that they want to leave the on-premises environment?”

There is a joke going around the internet about cloud: “There is no cloud, just someone else’s ops team.”

It’s funny because it’s true. While the current rise of cloud has everyone agog about the possibilities and amaze-balls stuff that the cloud can do, the reality is that there is no magic there. Everything that folks like us or Amazon are doing are things you could in theory, do on-premises.

However, in practice cloud is totally different. Why is that?

• Cloud is about scale. There are some things that are difficult or impossible to do unless you have massive scale.
• Cloud is about on-demand. Because of #1 above, you can usually just show up and ask for things.
• Cloud is about a customer-centric business model. This is less obvious and often forgotten. Cloud assumes a customer-centric business model.

On the other hand, most enterprise IT organizations have different priorities and missions. Normally, IT is tasked with things like ROI, security, stability, etc.. These goals are often in direct conflict with what a developer is trying to do.

In reality, developers are not really running towards cloud. What they’re seeking is getting the freedom to do their thing the way they want to do it.

To say it another way, it’s not them. It’s you.

Cloud flight may be a problem for your organization or it may be just fine. It really depends on what your overall cloud strategy is and how you plan to support those applications AFTER they get developed. The issue for IT is not massive movement to cloud. The absolutely terrifying thing is when YOU DON’T KNOW WHY you’re doing it.

As we discussed in our blog post about IT portfolio management, it is very common for applications to move from “High Potential” where cost is less of an object to “Key Operational” where cost is the #1 consideration over time. Thus, the long term impact of this trend is that you may be “stuck” with applications that were developed for a specific cloud platform that is no longer appropriate for the economics of that platform.

The reality is that there is no one answer that is correct for every organization and every application.

What you need to do is to think about your long term goals and then align your IT policies and procedures to optimize for those goals.

For example, if you have internal development teams that are working on applications that are core to your business, you will want to have a multi-year strategy about how you will manage those applications throughout their life-cycle. This strategy will then inform the platform and tooling decisions you make.

In the end, you cannot force tooling and platforms to your application development teams. Because of public cloud, they can simply take their business elsewhere.

This means that you need to be a true service provider to your internal customers and to focus on what they really need from you.

Like any business you will have to identify your target market and decide what business you are in. Not all customers are worth the cost of acquisition and you may choose not to service all internal customers all the time. That’s OK. One huge mistake that IT makes is to assume they are the only game in town and try to be all things to all people. That way leads to madness. You may not be able to serve everyone. Again, that’s OK.

The other aspect of this plan is to think about what your internal customers really NEED as opposed to what they say they WANT. The difference between expressed customer wants and actually (usually unexpressed) NEEDS is the difference between mediocre businesses and hugely successful ones. There is a great book about this subject by Mahan Khalsa called “Let’s Get Real or Let’s Not Play.” I highly recommend this book to any/all IT leadership seeking to transform their IT organizations into customer-centric service organizations.

To summarize, why are developers moving to public cloud and away from on-premises?

1. You are not meeting their needs.
2. They have business needs that you cannot meet.
3. They have a real business need that means public cloud is the correct place for them to be.

If you are in case 2 or 3, you are probably fine. However, if you are in case 1, I would seriously look at this and figure out what is really going on.