When I Quit my Job

February 6, 2010

I was reading this short post from Seth Godin and I realized that this is exactly one of the top reasons (if not the top one) why I left companies in the past.

When I found myself just doing was I was told to do, it was time to leave. It meant that either the culture of the company, the style of my manager or my attitude toward the job was not right for me anymore.

When my manager tells me what to do too often, there is less room to add value, try things, fail, learn. That’s not good. When I let my manager tell me what to do, it means that my heart is not in it anymore. Either way it is time to leave.

Of course there are times when you just have to do something the way they tell you to do it. It is sometimes part of the (learning) process. Here I am talking about when this is the norm, when this is the prevailing culture. There are very successful companies where this management style just works (I can think of a particularly big one :) ), it is just not for me.

Vittorio

4 Comments | Corporate Culture | Tagged: , | Permalink
Posted by vittorioviarengo

The Guerrilla Guide to Interviewing Product Managers

January 21, 2010

I have been asked for advice on interviewing product managers. I started to write down some questions and ended up with this more comprehensive memo, so I decided to turn it into a post. This post builds upon Joel’s “Guerrilla guide to interviewing” which is definitely required reading.  Everything from that post still applies but the detailed programming questions. Instead, here I propose questions and interview strategies specifically designed to find great product managers.

It has been a little while since I interviewed product managers, so I am a bit rusty ‘cos interviewing takes practice. I am planning on coming back to this post and add new things as they come back to mind.

The Product Manager

First things first. Let’s define what a product manager does. To me a product manager defines the “What and Why”.

The “What” covers the definition of the product, the set of features, what goes around it (packaging, pricing, support, documentation etc)

The “Why” covers the reasons why EVERY single thing that goes into the product is there.

I use the “what and why” extensively during the interview. I want to see if a PM is intimately familiar with every What of the product and very importantly for every what there is a clear Why.

Unlike Microsoft-like program managers, Product managers are not concerned with the “How” which is the realm of engineering but they should have enough technical knowlesge, experience and credibility to have good opinions about the how and ood judgment.

But it is important to keep responsibilities clearly separated. Engineer scan and should have opinions about the “what” and PMs may have input into the “How” but the ultimate responsibility to make calls stays within each organization.

If you are implementing the role of a Program manager as per the Microsoft school, then this is slightly different. In this memo, I will talk about the more traditional silicon valley product manager role.

Passion

This is one of the most important attributes for me. This is somewhat subjective as other people may value analytical skills over passion, this is just me. I look for passion in these three areas in priority order

Customers

Good product managers LOVE their customers. They understand their pain, their use cases, their roadmap an their business priorities. It is passion for customers that drives the definition of some of the best products. Moreover love for customers is the key ingredient for sustained success.

Interview Tactics and Questions

I throw them a soft ball to start. Talk to me about the product you built in the past and where you had the most fun and/or you had the most impact.

Here I am looking for the eyes to light up (passion) and I am listening for thing like “Customers were trying to do this…”, “Customers were struggling with…” you get the idea. I want to see if the candidate understands the customer pain and use cases.

  • Then I probe to see if they measured the impact they had on their customers.
    • What was the product ROI?
    • What were the metrics impacted by a given features (Opex, Capex, ease of use etc)
  • Talk to me about your most critical customer escalation and tell how you handled it.
    • Again I am looking for his/her ability to address customer issues while balancing company priorities.
  • Tell me about a time when you had to say no to a customer? Why? How did you handle it?
    • You want to know that the candidate knows how to say no (a great treat for a PM) when it is the right answer.
  • Why?? A great strategy when interviwing PMs is to ask “why” many, many times. Remember? Defining/knowing the “Why” is a big part of a PM’s job description so they better have great answer to that question.
    • Why did you build that product?
    • Why was that feature important?
    • Why did you cut that other feature?
    • Why did you move the release date etc.

Engineers

Good PMs love great engineers. They know how to work with them, unleash them and get out of the way, standup to them when needed. A PM relationship with his/her engineering team is key to the success of the team and the product.

You really want to see a balance of power. Whenever you see one of the two teams pravaling on the other it is bad news.

Here a set of questions I use

  • What is the worst thing you have done to an engineering team
    • Every PM made mistakes in his past. Some of these mistake may have impacted engineers. For example, not cutting deep and early enough, or not having clearly defined and prioritize product features. You want to know that the candidate had thought about these issues.
  • Describe to me the best engineer you ever worked with and why.
    • What made him/her great?
    • What did you achieve together?
      • Every PM has great stories about great engineers. If they don’t they either don’t love working with engineers (very, very bad sign) or they have not worked with great engineers (another very bad sign). You want to know that your candidate has some good stories and tell them with passion
  • In your opinion what is the different in productivity between a super star engineer and an average engineer?
    • If they hesitate (which is kind of a bad sign), I make it easy for them and ask them “Is it 150% or 10 times?”. Of course there is no numeric answer, but if the candidate says 150% then they have never seen a super star engineer, clearly. Pass.
  • Say you give your engineering team a list of 10 features for a product release, they come back and say that can implement 6 from your list and 3 that you did not think about, what do you do?
    • Good question to see how well the candidate understands the give and take relationship with engineers. Also you want to see how s/he approaches the 3 features coming from engineers. Is s/he excited about what these ideas can be? Does it turn them down a priori ‘cos they were not on his list (clearly a deal breaker)
    • Then I double down and I ask “say that one of the three features coming from the engineering team does now make sense to you, what do you do?”
      • Again, you want to see if they know how to pick their battles and make the right tread offs.

Innovation

I love when innovation is a company value. What in the world does it mean to have innovation as a value? You either have the right people or you don’t. Innovation does not happen because it is written in a company manifesto. Anyway, ranting apart, here I’m really trying to see if the candidate understands innovation, if s/he has lived it in the past. Can s/he think outside of the box, has he built products that were different, that broke with the past? Again, note that there are cases where you are looking for a farmer more than a hunter, in which case this attribute may not be as important. In any event, if you are recruiting for a farmer type of  position you may be not able to attract innovator, so the point is moot.

What question do you ask to find this out?

  • You can start with a soft ball and ask to describe a past project that was particularly innovative. From there you dig deeper and for every feature mentioned as differentiating, ask why 3 times. Again, always go back to customer pain addressed and how that particular feature helped  customers get their job done better, faster, cheaper or/and easier.
  • Ask about the competition. How did the product/feature help you competing? How was it different?
  • If you have time (well, you should make time) ask them to define the requirements for a new version of an existing product. I use this in many different ways. In this case you would look for the candidate’s ability to look at an existing mainstream product and define new features or different integration points with other products based on latest technology available (e.g. instant messaging integrated with email in the browser) that display out of the box thinking.
  • Don’t stop at technical features, sometimes the best innovation is around business model, sales channel, and so on.

Technical Skills

I subscribe big time to Joel’s school of thought on hiring for talent and skills, NOT knowledge. Smart people will figure things out. Still, depending on how technical is your product, you want PM that can go deep on the technical side and have meaningful conversation with their engineering counterparts. These are the overall question you need to answer as the hiring manager

  • Can they gain the respect of the engineering team?
  • Do they have enough technical skills to make good judgment calls?
  • Do they have enough technical chops to recognize great ideas coming form engineers?
  • Do they have the credibility to have engineers trust their judgment calls?

Here are some point questions

  • What was the theme of a given product release (from their resume)?
    • Look to see if s/he understands release themes and more importantly how to use themes to focus the release and cut features

Priorities

  • What was the most painful cut you made in this or that release?
    • They need to know this cold. PMing is more about what NOT to do than about what to do. If they cannot clearly articulate this, just pass. You are looking at a bad PM.
  • If I called the lead engineer for that project what would s/he say about you?
    • You are looking for clues of credibility, honesty and confidence here.

Technical Knowledge

Whenever you see an opening to drill down on something technical do it.

  • Why was that (____put some technical thingie that the candidate brought up here ___) important?
    • You are not looking for the point knowledge here, you want to figure out if they understood the technical reason why this was important for customers.

Requirements and Priorities

  • One way to see if they have a good sense of priorities is to ask them to write the list of top requirements for a well know product (same as above), but here you are really digging into the “Why”. For example
    • Tell me an application that you are very familiar with and you use every day. Then ask them
      • What drive you nuts about it and how would you fix it
      • If you were the PM for this product, tell me what would be the theme of the next release. Why?
      • What would be the top 5 features?
        • For each feature then drill down into the ‘why” it should be there. He is the customer of the product, he should know the use cases and pain points.

Out of context requirement question. I believe a good PM gets mad at bad products, bad processes and in general things that are poorly designed. PMs are professional problem solvers, always looking to improve things around them.  I sometimes asked them to define the requirement for products that are completely outside of their specific domain.

  • For example, I ask them if they travel for work, then ask them to define the requirements for a more efficient airport security procedure.
    • I am looking for them to be mad at something “I hate the way they handle the security lines at airport” but I don’t stop there (I am not looking for a whiner, I am looking for a problem solver), so then I ask them how they would fix it if they were in charge.
    • Look for something that they are very familiar with, not something you like or understand.

Analytical Skills

  • You do want your PM to be analytical but I find that when people who are very passionate and innovative are sometimes not super analytical. That’s Ok as long as the team overall compensate for this.
  • I am not sure how to assess this in an interview. I am open for suggestions.

Not just Features

It is not just about features and functions. Drill into other things what makes a product. Pricing, market, support, release cycle etc.

If they built a new product see how they went about it, how they validated the idea, the market opportunity, how/if they did early customer testing.

If they built mature products, see if they were formal about analyzing market, customer, support, field and revenue data.

Sales

This is important. Do they understand the challenges in selling products? Did they take the time in their past career to go out in the field and feel sales people’s pain? Do they know how to establish a great working relationship with the field?

Some example questions:

  • Do you have an example where you were instrumental in closing a deal? What was your role? What did you do?
  • Was there anything specific you did to make it easier for the sales guys to sell the product? Explain.
  • How did you prospect customers for that particular product?
    • An easy question to see if they even tried to put themslef in the sales people’s shoes
  • What sales model did that company implemented?
    • See if they were intimate with the sale model, direct, indirect, overlay etc.
  • If you had a chance to change the go to market approach for a previou product, what would you do? Why?

Mistakes

Everybody makes mistakes. Ask them to talk about one and see what they learned from it. You want people who are honest and open about mistakes. If they get defensive, it is a bad sign

Soft Skills

These are tough to evaluate. If you are the hiring manager, I do recommend to meet with a candidate three times.

  1. First for an introductory meeting get to know each other, assessthe chemistry
  2. Then for the formal interview. Make sure every key person that will work with the candidate has a chance to interview him/her. Not just in the PM team but across team: Engineering, Marketing, PM, ideally a System Engineer or sales person.
  3. Finally for the closing event and presentation of the offer. I pulled out of giving a candidate an offer at this stage. What happens after you see a person for the third time is that some of the main characteristics of their personality will become more evident. For example, if you felt a little arrogance the first time you meet them but you were not sure how bad it was, by the third time meeting if they really are arrogant they will start bragging and you will know. I gave up on a great candidate because I got a hunch that he was a whiner and by the third time we met he could not stop going on and on about how everything that ever went wrong with in his career was somebody elase’s fault. And I thought “Really??”

Let’s get back to soft skills. What I generally look for is the following:

Good Listening

PM is a lot about listening. Listening to customers to gather requirements and feel the pain, listening to sales people to learn how to help them sell the product, listening to executives to understand the company priorities, listening to engineers for great ideas and even listening to angry customers who are having a problem.

Are they good listener? Do they listen carefully and ask good questions before giving their answer?

Context Switching

PMs sits between an engineering team and everybody else. They interact with multiple organizations multiple times a day. They get interrupted often and they context switch a lot.

During the interview, whenever I see that the candidate is on the right track, I move to the next question, and then at the first chance I go back to a previous topic and see if they can take it from when we left it. I do this multi times during the interview. It allows me to see how well the context switch.

Communication

Communication skills are very important for product managers. You can assess this throughout the interview but you may want to ask them a couple of point questions here to see if they can be crisp and compelling in their communication. For example

  • What was the elevator pitch for that product?
  • How was it different from the competition?

Confidence

If a PM is to be able to lead great engineers, make tough calls, handle customer escalation, they need to be confident. I don’t mind calling them wrong on something they are absolutely right on to see how they react. Do they stand for their opinionor do they quickly back down?

Puzzles

I generally agree with Joel on using puzzles in interviews. I have seen SUPER smart engineers (let alone PMS) miserably fail on relatively simple puzzles. Still, sometimes I do for PMs as it I allows me to see how they think on their feet, if they think out of the box, if they engage. This is tricky thou. You need to make sure they understand this is a way to engage together and they are not going to be judge solely on the puzzle.

Team

A lot have been written about this topic but I do want to bring this up because this is indeed a key treat of a good PM. Product management is a lot about leverage, working with multiple people AND multiple teams to get stuff done.

You can tell a lot about team playing when you ask them about engineers and customers above, but overall you want to heard a lot of “we” and very little “I” in the candidate’s answers. “We really nailed that product release”, “we pulled it off by doing this and that…”. You want hear enough “I” though that gives you comfort that the candidate is confident and impactful. Tough balance.

Conclusions

Great PMs are very hard to find. Hiring a bad PM and empowering him/her is one of the worst things you can do to an engineering team. Hire a good one and see them argue passionately about customers, great technology, great people and thrive together.

Leave a Comment » | Product Management | Tagged: , , | Permalink
Posted by vittorioviarengo

Care and Kick Butt!!!!

January 12, 2010

Like a lot of you I have been through my share of companies each with their own corporate values. All of them sounded good on paper. Heck, they are designed to sound good!!

But here is what I found the problem with them is:

  • Values are only meaningful if they are lived every day, if they are put into tangible action by the management team down day in and day out.
  • As I get older I have a hard time with long list of things (where long is 5) and the product manager in me reminds me that having short and sweet priorities is paramount

So, after years of working in, leading, studying teams and organizations, I think that if I had a company on my own again I would boil the company values down to two. Ready? Here they go:

  • Care
  • Kick Butt

<—- emendament Gordon makes a good point in the comment below, so I am revising this already to 3 points:

  • Be Honest
  • Care
  • Kick Butt

‘cos if you are not honest you may care about the wrong things and kick butt in the wrong direction

—->

Wherever you see excellence, you see people who care and kick butt. They care about their customers, the product they build, their colleagues, their families, their communities… and they kick butt, ‘cos if we just care but we don’ act on it… well we are just useless nice and caring people :)

Just a clarification: this does not mean that I am leaving or even considering leaving VMware. I love this place and I am here for the long run. It just hit me that these would be good, concise values for a company.

Vittorio

3 Comments | Corporate Culture, Product Management | Tagged: , , | Permalink
Posted by vittorioviarengo

IT Production Phase Drill Down

January 5, 2010

In previous posts, I covered the 3 main stages of virtualization adoption and the key elements driving the virtualization journey. Just a reminder that most of the material in these posts comes directly from our customers through a primary research project that we carried out last summer.

Let’s now double-click on the IT Production phase.

In this phase the IT department is the main driver for virtualization in a bottom up type of approach. They virtualize the assets that they own such as file and print servers, domain controllers, web servers, Citrix servers, and so on. Test and Dev servers are also a primary candidate for virtualization at this stage.

Key Drivers

Here is the typical status of the key virtualization drivers in IT production:

Confidence

The confidence is reactive, meaning that the team has enough knowledge and experience to react to certain triggers (see blow for the list of typical triggers) but virtualization is not the predominant computing platform yet. The team knows how to install and operate ESX/ESXi but they are typically not familiar with more advanced features like SRM, DRS, HA and FT. There is a big inflection point in term of confidence when the team learns how to use vMotion as it allows them to perform system maintenance without downtime. It is not unusual to see customers organize internal demos around vMotion to show its power to other divisions and/or to the business.

Sponsorship

The sponsorship at this stage is typically at the IT manager or IT director level, especially in bigger companies. In smaller companies the CIO has more visibility into most projects going on in his or her org. In many cases, we cannot even talk about sponsorship as much as ownership as IT tends to virtualize what they own first.  There are cases where the sponsorship is at the senior level but in many cases the virtualization first policy is not enforced aggressively yet.

Value

The predominant value that drives virtualization in this stage is cost saving from servers consolidation. These saves are so significant that they overshadow some of the additional benefits the come from virtualization such as faster provisioning, better manageability, less downtime etc. More on business value further down in this post.

Obstacles

Our customers told us that at the beginning of their journeys, these where the three biggest obstacles  in the way of virtualization projects:

Team Communication

Or lack of thereof. Virtualization technology cuts across multiple teams and disciplines: servers, storage, network, and security. Virtualization is typically introduced into IT by the server team without necessarily involving the other teams that will be impacted by the transformation.

In many customers this has been the main obstacle to more efficient adoption and in turn value realization.

It is very important to:

  • Train all teams involved on virtualization technology
  • Keep communicating across teams as the transformation takes place over time.

We found customers who even re-organized their IT around virtualization to facilitate adoption and optimize their processes.

Virtualization FUD

This is somewhat related to the previous point. As much as virtualization has become mainstream in thousands of IT shops and it is running mission critical applications in some of the largest data centers the world over, there are still IT professionals that don’t fully understand how it works and what are its advantages. This is natural with any technology transformation but this FUD does get in the way of wider adoption of virtualization.

We learned some very interesting tactics that customers use to overcome this obstacle. Some examples:

vMotion Demo
This is a big hit amongst our customers. They use vMotion to show in a very effective way some of the things that virtualization can do for the business such as  disruption-less maintenance, lower risk from hardware failure, and so on. Later in the journey, the vMotion demo is replaced by demos of even more sophisticated features such as High Availability and Fault Tolerance.

Show and Tell
Virtualization champions within our customers often take the show on the road and they go around the company educating people about the technical and business advantages of virtualization. Sometimes they use a successful internal project that they did, some other times they just hold a virtualization workshop using material from our web site or other blogs.

Virtualize Under the Radar
At the beginning of the journey a lot of virtualization happens below the radar as IT virtualizes the assets that they own directly. Later in the journey FUD from application owners and the business side becomes more of a factor and slows down adoption. This is where we found that some of our most confident customers just go ahead and virtualize applications without really telling their business counterparts. I know, this is controversial but true. The attitude of  these customers is along these lines: “I don’t let the business tell me how to run my infrastructure. If I decide that virtualization is the right computing platform for a given application, I just do it”. If you think about it, the business does not really care what brand hard drive IT uses right? Overtime the same will be true for whether an application or a database runs physical or virtual. It is indeed true for some customers today where virtualization is the default computing platform. It is a factor of their confidence, credibility and experience.

Storage Architecture

Storage architecture is the third major obstacle we found in IT production. Many of our customers told us that if they could do it all over again they would spend more time figuring out the right storage architecture from the get-go that

  • works well with virtualization (and vMotion and all the advanced virtualization features)
  • supports future growth

I am not the right person to go deep on this issue. I will look for an expert at VMware and interview him or her about storage best practices in one of the future posts.

Triggers and Capabilities

As covered in this post, we developed a framework to model the relationship between business triggers, VMware product deployed, resulting capabilities and business value realized.

In the IT Production stage, these are the typical business triggers that ignite a virtualization project:

  • Major hardware refresh
  • Data center migration/ consolidation
  • Merger / acquisition
  • Standardization/Organizational Change
  • Outages (application, system)
  • Increased capability/ confidence
  • Cost cutting initiatives
  • Capacity constraints (power, cooling, CPU, space)

Customers respond to these triggers by deploying the basic virtualization platform around ESXi with related management tools (vCenter).

The capability that are achieved by deploying these products include:

  • Massive consolidation
  • Space, cooling, hardware, energy savings
  • Have a lot more floor space
  • Faster Provisioning
  • Do more with Less
  • Excess capacity for future growth

Faster provisioning in particular is a capability that fosters more adoption of virtualization and positively impacts the IT team credibility. It is not unusual for customers to cut down their provisioning cycle form weeks to days, sometimes hours.

These capabilities map pretty directly into the following business value categories

  • Capital Avoidance Saves
  • IT Operations Efficiency
  • Green Saves

Where the predominant value is Capital saves from consolidations as mentioned above.

Development-Related Triggers

There is also another set of triggers that prompts customer to deploy VMware’s development life-cycle management area such as Lab Manager. These triggers include:

  • Major application upgrade/Changes
  • Need to improve application life-cycle efficiency/ quality
  • Major OS refresh

From deploying this area of the VMware product line customers typically get these set of capabilities in return:

  • Reduce the cost of application development life-cycle
  • Faster set up of development seats
  • Reproduce bug/incident events for resolution
  • Replay events to identify incident root cause

This is probably the first area in most customers journeys where the value proposition from virtualization is not predominantly around cost saving from consolidation. There will be many more examples in the following stages (Business production and ITaaS, see this post of an overview).

In fact, when deploying products such as vCenter Lab Manager, customers typically realize lower cost for their testing infrastructure, increased application development efficiency and faster time to market for new applications.

What’s Next

In the next post, I will cover some of the IT Production best practices that we learned from our customers.

Vittorio

Leave a Comment » | IT Production, Virtualization Adoption Phase, Virtualization journey | Tagged: , , , | Permalink
Posted by vittorioviarengo

The Virtualization Journey for ISVs

December 22, 2009

The Journey stages I discussed in this post cover most of the customers we interviewed so far.

There are few exceptions. I talked about the case where customers start their journey in the Business Production phase virtualizing production databases. A minority.

There is also another pattern that is notably different: ISVs (Independent Software Vendors).

ISVs make software for a living, so optimizing their Dev, Test, QA environment is mission critical for them. Moreover the number of test and dev servers they own typically outnumbers the servers they use to run their business.

As a result their stage I (test and dev) is both much prolonged and much bigger in scale. One may say that they reach stage 3 which is typically characterized by >50% virtualized servers without ever going through phase II (Business production).

For example, I interviewed a large ISV last week. They have 18,000 test and dev servers vs. <200 servers that run business applications. They virtualized 50% of their test and dev servers saving north of 20 million but they have not tackled their business applications yet. In a typical enterprise customer scenario when the virtualization percentage reaches 25-30%, that’s when customers typically start virtualizing business applications and databases switching the value proposition from server consolidation to better SLA and business continuity. In the ISV example above, virtualizing more test and dev is where they are going to get the biggest business benefits as they are vastly improving their development efficiency and the quality of their software while at the same time cutting support and hardware costs.

Besides aggressively virtualizing more test and dev servers on their way to 100% virtualized environment, they are also increasing the level of provisioning and management automation by deploying self-service capabilities. Their  target is 30% self-service penetration within a year.

In summary, although the three stages of adoption apply to most enterprise customers, there are exceptions that highlights interesting use cases and best practices.

All scenarios seem to have one thing in common thou: what drives high level of virtualization adoptions are clear business drivers that are beyond server consolidation.

Vittorio

Leave a Comment » | Test & Dev, Virtualization journey, vmware | Tagged: , , , | Permalink
Posted by vittorioviarengo

Virtualize Production Databases First

December 19, 2009

Now that I got your attention…. let’s talk about a couple if customer interviews where virtualizing production databases came up and the first step of their journey.

In the Customer Journey stages post, I covered how the majority of the customers we interviewed start their journey in the IT production stage where they virtualize test and dev servers and IT infrastructure applications like file, print, domain controllers and so on.

There are exceptions. The more interesting one is when some mid-size companies (say 1000 to 20,000 people)  start their journey virtualizing critical production databases. I personally talked to two of them and heard about others from our system engineers.

Why do they do that? Most customers virtualize production databases and business applications in what we call the Business Production phase. What made these other customers start from databases?

There are tons of material about how to best virtualize database on VMware. In this post I want to cover what I learned from a business perspective from these two aggressive customers.

Biggest Bang for the Buck

Both of the customers I talked to said that virtualizing databases would give them the best bang for the buck based on better management, better performance, better quality of service. DB License saving was also mentioned as a factor.

They both sold the project internally around, and I quote:

“Databases will run faster and will have better management and instantaneous failover capability”

“I wanted to give my customers (the business owners of these databases, that is)  more memory, more network and more CPU, VMware running on updated hardware allowed me to do that”

“I demonstrated and documented that performance was going to be better in the new virtualized environment”

They did not sold the value proposition of server consolidation, although it was definitely a factor.

So, how does a database run faster in a virtual environment? Well, most of these databases were running on relatively old and under-utilized machines. By upgrading them to a new modern server running VMware, these customers could allocate more resources to each database instance therefore achieving better performance.  Moreover, thanks to VMware HA and FT, they could provide their internal customers with better business continuity without deploying more complex clustering solutions from the database vendors.

Although consolidation was not the main driver, one of the two customers went from 200 physical servers down to 25. He said he was not too concerned with the consolidation ratio anyway as he wanted to keep some performance buffer in there just in case. The intent is to be more more aggressive at the next refresh cycle once he has more data about how the databases perform over time. This is definitely a best practice we heard form many customers in the Business Production stage.

Everything Else Will Be Easy

Both customers said that one of the reasons they chose production databases as the starting point of their journey was that by making them work they would get instant credibility for their team and for virtualization. This would make it easy to virtualize less mission critical workloads going forward and would take the FUD about virtualization off the table for ever.

It is not by chance that both customers have a >80% virtualization penetration and are working actively to get to 100%.

Confidence+Sponsorship

How did these customers jumped stage one (IT Production) and be successful?

As covered in the this previous post, the key drivers of successful virtualization journeys are Sponsorship, Confidence and Value. Both customers had the three elements taken care o:

Confidence
Both technical leads where highly competent, credible and involved in the technical details.

They both formally trained their teams, and not just the server team but also network, storage and security. One of them did not trained the network guys initially and regretted it later and some of the network architecture had to be redesigned later in the process. This is too a best practice. Formally train the team on virtualization across multiple disciplines.

Sponsorship
Both technical sponsor were very senior in the technical ranks and had a direct path to the CIO who was involved from the beginning and both formally reported the technical and business results achieved to the top.

Value
Both customers skipped the IT production phase where the prevalent value proposition is cost savings from server consolidation and went directly to phase two. Interestingly, the value proposition that they used to sell the project internally and to track the business value delivered was around business continuity and quality of service. This is very consistent with other customers who got to stage 2 after going through IT production first. The difference is that these two customers moved much faster in their virtualization journey after establishing their credibility virtualizing mission critical databases in their first project.

Conclusions

I would not suggest to start the virtualization journey from production databases to most customers, but now I have seen it work for some.

Maybe we should create a swat team at VMware that goes around and does this full time. A way to accelerate the journey?

Vittorio

More information about virtualizing SQL Server here: http://www.vmware.com/solutions/business-critical-apps/sql/

and Oracel DB here: http://www.vmware.com/solutions/business-critical-apps/oracle/

3 Comments | Databases Virtualization, Oracle Virtualization, SQL Server Virtualization, Virtualization Adoption Phase, Virtualization journey | Tagged: , , , , , , | Permalink
Posted by vittorioviarengo

Virtualization Journey: Product Adoption

December 3, 2009

In the “Key Adoption Drivers” post, I covered what the main drivers for virtualization adoption are and in the “Virtualization Journey Stages” post we saw how the virtualization journey evolves along three main stages that are characterized by:

  • Different type of applications being virtualized (IT infrastructure, test and dev, business applications, databases…)
  • Level of organizational and process maturity
  • Different business value delivered

The three stage framework represents the first axis of the virtualization journey adoption:

Business Value Evolution

One of the most interesting findings from our customers interviews was how the value proposition that virtualization delivers evolves across the journey. Mind you, I am talking about what customers told us, not what VMware marketing says.

At the beginning of the journey (IT Production), it is all about cost efficiency around server consolidation, space, power and cooling savings.

When customers enter into the Business Production phase and they start virtualizing business applications and production databases, the value proposition is all around better quality of service and business continuity. This shift is sudden and dramatic. It is like cost savings from consolidation is taken for granted at this stage and customers switch their focus on faster provisioning, better capacity management, reliability and process automation for their business applications.  This is where features such as High Availability (HA), Fault Tolerance (FT) and SRM become important.

At the right side of the journey, it is all about business agility. Customers are on a path to virtualize as much as they can of the IT environment so that they can scale up the benefits derived from virtualization and achieve more process automation, faster time to market, and dynamic allocation of resources to cope with varying demand. This is the stage that gets them closest to running a private cloud. More on this in later posts.

The Second Axis of Adoption: the VMware Product Stack

The journey also evolves along a second axis: the VMware Product Adoption that is which functional areas of the VMware product portfolio a customer deploys overtime.

There are five main functional domains in the VMware product portfolio (pre-SpringSource acquisition):

  • Infrastructure Consolidation (ESXi and core vCenter)
  • Application Development Quality and Efficiency (Lab Manager)
  • Cost Effective Availability and Disaster Recovery (SRM, HA and FT)
  • Desktop Security, Mobility and Support Efficiency (View, Workstation)
  • Virtualization Efficiency and IT process Automation (DRS, Lifecycle Manager)

The core platform  with ESXi and the basic management capabilities of vCenter provide the foundation for hardware abstraction, consolidation and CAPEX savings along the whole journey. To unlock the higher level business value of virtualization, customers need to adopt and deploy the upper layers of VMware product stack.

SpringSource add some very nice application management and monitoring capabilities with Hyperic, a lightweight development framework (Spring + Tools) and a lightweight run-time container (tc Server).

Although adoption stages and product adoption are somewhat related (e.g. customer who virtualize mission critical applications tend to aggressively deploy features such as HA and FT),  each customer will follow their very own path in deploying the different functional areas of VMware’s product stack. The path mainly depends on what their business triggers are (e.g. running out of data center space, hardware refresh, security compliance on the desktop) and their business priorities.

Business Triggers to Business Value Framework

As part of our customer journey project, we built a taxonomy to map triggers to functional areas, to capabilities to business value. This is how we help customers define the custom journey that best maximize business value returns based on their set of triggers and concerns.
To do so, we first enumerated all the business triggers that are relevant to virtualization; then we mapped which product area addresses each business trigger. From there, we listed all the capabilities and the business values that each product area delivers.

This is the high level view of triggers-to-business-area mapping by stage:

And this is the drill down for the set of triggers the typically spark the deployment of Lab Manager.

And the related capability and value mapping

In the next posts, I am going to show how we use this framework to build a customer adoption journey and then how we calculate the ROI across the different business value categories: Cost Efficiency, Quality of Service and Business Agility

2 Comments | VMware Product Adotpion, Virtualization Adoption Phase, Virtualization journey, vmware | Tagged: , , , | Permalink
Posted by vittorioviarengo

VMWare Community Interview and QA

October 22, 2009

Virtualization Journey Q&A Podcast

Today I had a great Q&A session with members of the VMware community about the virtualization journey. The call was facilitated by John Troyer who runs our VMware community and it has been recorded here.

Lively exchange of ideas and great feedback!!

I covered the key elements that drive the adoption of virtualization technology and the three main stages of the journey, then we had a great discussion about adoption obstacles, sponsorship, and organizational structures.

A coupe of takeways

Controversy

When I present our findings on the virtualization journey, there is often controversy around the Business Production phase. As a reminder, the business production phase is when customers virtualize mission critical business applications and databases. This is when IT operations work side by side with Application Owners (e.g. the person who is in charge of running SAP) to virtualize business applications. entering this stage is a critical inflection point as virtualization moves from being an effective tool to consolidate servers (and save power, space and money in the process) to a computing platform that provides better business continuity, disaster recovery and improved SAL (Service Level Agreement).

Some of the best practices that we heard people use to tackle this phase sparkle some very animated debates.

My favorite one is the following:

Best Practice #1:Publish a Roadmap

According to this best practice, when you virtualize business applications you should always tell the application owners and LOBs why you are doing it and what’s in there for them. Many customers do this. They publish a roadmap, they get the app owners comfortable, they execute, track results and share the success stories with other LOBs.

Best Practice #2: Don’t Tell Them

In this best practice, IT just does it. They virtualize business applications and they don’t tell the app owners. Their attitude is “they (LOB) should tell me how to run my infrastructure. I know this technology works and I just do it”.

We absolutely heard both practices applied successfully by different customers. When I bring this up people react violently to either #1 and #2 above. I believe it depends on their level of confidence (the more confident tend to just do it) and level of maturity. In any event, this controversy came up three times in three presentations I did on this at VMworld, with a delegation of CIOs yesterday here at VMware and today during the podcast.

I am just reporting what I heard from customers. Different strategies for different customers.

CIO-Level Sponsorship

The level of sponsorship for virtualization projects evolves over time from lower levels in IT all the way to the CIO at later stages. Today when talking about the Business Production phase, I mentioned that some IT organizations have to convince one application owner at the time about going virtual. Somebody in the audience was very vocal about the fact that companies should go through this phase with a mandate form the CIO in place. This provides the right air cover to address the skeptics objections and move forward swiftly. I could not agree more. The fact is thought that many customers don’t have that top level mandate at this stage and they consequently struggle.

This is an area of focus for us as a company going forward. More on this later.

Keep the feedback coming.

Ciao

Vittorio

3 Comments | Virtualization journey, vmware | Tagged: , , , | Permalink
Posted by vittorioviarengo

Virtualization Journey Stages

September 25, 2009

In my previous post I talked about what are the key elements that drive the adoption of VMware virtualization technology in our customer base.

After looking at dozens of customer journeys directly and  indirectly through various customer proxies (Sales Account Managers, VMware Consultants and Technical Account Managers (TAM), etc) we find that customers are in one of three stages that we are going to call:

  • IT Production
  • Business Production
  • ITaaS (IT as as Service)

There is also a stage zero where companies just experiment with the technology. I am not going to address this phase here. I am concerned with projects that take virtualization into production like with all the customers we interviewed in the journey project.

The chart show all key elements for adoption: Sponsorship/ownership, Confidence and Value. These evolve pretty significantly over time with two major inflection points along the way.

Each of these three stage is worth its own post. In this article I will address how the journey evolves at the high level.

IT Production

This is the Cost-Efficiency phase, building the core technology and skills base by virtualizing IT-owned applications, and benefiting from the value of server consolidation.

Sponsorship/Ownership
In the IT Production phase, IT organization virtualize what they own. In fact at this stage it is not really a matter of sponsorship, it is more matter of ownership. They are comfortable with the technology from previous experimentation or deployments and they are now ready to virtualize the applications where they don’t need to ask permission to the business.

Confidence
At this stage, confidence can be characterized as reactive. The team reacts to a business trigger such as hardware refresh or data center consolidation by using virtualization technology. They typically deploy the VMware hypervisor and the core management platform and they start virtualizing the low hanging fruits: File,Print, Web servers, domain controllers, Test and Development servers. At this stage they are building up their virtualization skills. They don’t tackle applications that are perceived to be riskier or that require them to fight tricky political and cultural battles. Just not yet.

Value
The predominant value proposition in this phase is consolidation of IT infrastructure to save on hardware, space and cooling. Customers also end up with some nice by-product and capability such as faster provisioning, a better storage infrastructure (required to deploy VMotion and other useful virtualization features). This creates the technical and knowledge platform to target more interesting applications and for future growth.

Business Production

The Quality of Service phase, tackling business applications (such as Microsoft Exchange, SAP, Oracle Apps, Databases etc) while adopting more of the VMware product stack (such as DRS, SRM or View) with a rapid switch of the value proposition towards better SLAs, business continuity and overall quality of service.

This is a major chasm that customers have to cross on their way to high level of virtualization penetration. I will probably spend multiple articles on this phase in the future, addressing triggers, obstacles, best practices and examples. This is just a quick summary.

Sponsorship
In the Business Production phase, the IT organization which is driving the virtualization agenda needs to find new level of sponsorship for the journey to progress. They have virtualized all the low hanging fruits, everything that they owned. Next step: business applications.

To do so, they now need to get the “Application Owner” on board. Application owners bring about new concerns besides saving money by consolidating servers. They care about performance, lowering risk, quality of service, time to market for new versions of the application, business continuity, planned and unplanned downtime. This is why every single customer we talked to who is in this phase learned how to address these concerns by painting a different value proposition than just server consolidation. They use VMware product features such as SRM, High Availability (HA) and Fault Tolerance (FT) to provide better quality of service (and performance) for their business applications running in a virtual environment.

Confidence
Confidence can be characterized as selective at this stage. The team carefully selects the first applications to virtualize based on a path of least resistance for their organization. “Do I have a good relationship with that application owner?, “Do I have skills to virtualize the application in question?”, “What are the risks associated with virtualizing it?”, “What are the risks associated with NOT virtualizing it?”, “Does the ISV support the application in a virtual environment?”, “Is there a compelling reason to virtualize this particular app (lack of HA, deploying a new version, non-satisfactory uptime…)?”…

Often the seed for virtualizing a business application is planted when a new version is being developed and tested. This process may already be happening in a virtual environment and when the app is going into production, deploying it on a physical server introduces a risky architectural discontinuity. It often makes sense to just leave it running in a virtual environment and take it into production.

After the first couple of business applications are successfully virtualized things get easier, the confidence grows fast and soon the team is ready to take on most business applications. Evangelizing the success and the business value achieved is a critical success factor in this stage. We found that customers do very creative things to make this happen. I will share some of these stories in the upcoming posts.

Value
In this phase the predominant value proposition is quality of service along pillars such as business continuity, lower downtime risks, faster provisioning, time to market and so on. It is actually pretty interesting how dramatic is the change in the type of value people associate with virtualization as they make the transition from IT Production to Business Production. More on this below.

Virtualization First Policy

“Virtualization First” policy refers to an IT mandate by which the VMware-based virtualized environment become the default deployment model. Physical servers are only provisioned on an exception basis and only when there is a strong technical or business justification.

Many of the customers we interviewed have such a policy in place but there are differences in when they put it in place and how well they enforce it.

Timing
Some customers put this policy in place very early but they don’t enforce it very well and it is pretty easy to make the case for getting a physical server.

Other customers, put this policy in place for the type of applications that they have experience virtualizing at any of the three stages. In fact, the ability to enforce this policy is highly correlated to IT confidence and maturity around VMware technology.

Enforcement
Some other customers put the policy in place after successfully virtualizing few business applications. At that point virtualization tend to get on the radar of higher level of management in the organization and in the same way as increased confidence influences their ability to enforce the policy, increased level of sponsorship provides even better teeth.  When the sponsorship is at the highest level (such as in the ITaaS Phase), that is the ultimate enforcement and empowering function.

ITaaS

In the IT as as Service phase, virtualization is just part of what IT does. Everything new is deployed on virtual, and the value is all around time to market, process automation, and ultimately business agility.

Sponsorship
In this stage, the sponsor for the virtualization journey is all the way tot the top of the organization (typically the CIO). Tracking the value delivered over time raised the visibility of the virtualization journey and it is now a top initiative for the CIO, sometimes with MBOs associated to virtualization penetration and speed of adoptions for the CIO’s reports.

Confidence
Confidence is very high. Most of the product stack has been adopted, including SRM, DRS, Lab Manager, HA, FT and so on. The virtualization team is often folded back into the core server team as virtualization is just part of what IT does.

Value
At this stage organization are looking to scale their virtualization effort so that they can in turn scale the associated benefits that come from process automation, better resiliency, and increased quality of services.

Some customers refer to this state as their “internal cloud” when resources can be allocated on demand where and when needed. IT is nimble. Their credibility has improved throughout the journey and (in their own word) their quality of life is better. They don’t obsess about hardware failures because they know they can move the impacted VMs around. They use DRS to automatically increase resource allocation on the fly. They have a Disaster Recovery (DR) strategy or even a complete solution in place. They are looking at or implementing their desktop virtualization roadmap.

Conclusions

These are the three main stages that characterize most customer virtualization journeys we have seen: IT production, Business Production and ITaaS.

The adoption is driven by IT confidence, level of sponsorship and tracking the business value delivered by each project.

There is a major chasm/inflection point around the time customers move from virtualizing IT infrastructure services and tes/dev servers to their first business applications. When they do cross this chasm, the value proposition that they track, perceive and sell internally radically shifts from server consolidation and CAPEX savings, to better quality of service, OPEX savings and better business continuity.

What’s Next

In the next few posts I am going to

  • Talk more about the value path for virtualization and what is the relationship between business triggers, product functional areas, capabilities and value
  • drill down on each phase and use specific examples to talk about obstacles, best practice, evangelization techniques and so on

Ciao

Vittorio

4 Comments | Virtualization journey, vmware | Tagged: , , , , , , | Permalink
Posted by vittorioviarengo

The Virtualization Adoption Journey – Key Elements

September 15, 2009

As covered in previous posts, a VMware team of 3 people and I spent the last 4 months listening to our customers and learning how they move through their virtualization journey.

In the next many posts, I will share what we learned and I am looking forward to learning even more from the customers who will take the time to read these posts and share their stories.

The Key Elements

Across all the interviews that we did, we found that there are three key elements that drive successful adoption of virtualization technology:

Confidence, Sponsorship and Value.

Virtualization Adoption - Key Elements

Virtualization Adoption - Key Elements

The basic idea is that Confidence and Sponsorship (or ownership, more on this in later posts) drive adoption. Adoption delivers value that comes in the form of

  1. New capabilities/outcomes that benefit IT and the business after completing a project (e.g. faster provisioning time, better up-time, interruption-less hardware maintenance…)
  2. Business Value (e.g. Capex and Opex savings) derived from the achieved virtualization outcomes

1) feeds IT confidence, 2 feeds  sponsorship confidence which in turns gives IT the ability to get better and better sponsorship over time and funding for virtualization projects.

These three key elements don’t drive adoption in a vacuum. Each project is triggered by some sort of business or technical event such as running out of data center space, a hardware refresh and so on. We are going to call these Business Triggers. We are going to talk about type of business triggers and their impact on virtualization adoption and stages extensively in future posts.

This process is actually not unlike other technology transformations that IT organizations have dealt with over time. I will spend the reminder of this post articulating the specifics of how these elements relates to virtualization technology and its adoption within our customers.

Confidence

Confidence here refers to the confidence the IT team has in using virtualization technology. There is a clear correlation between IT confidence and how aggressive they virtualize their infrastructure.

Despite all the success that VMware products has had in the marketplace, there are still people out there that don’t understand virtualization and its value completely. I was one of them when I started here 6 months ago, virtualization sounded like magic to me. At times, this creates skepticism and resistance to adoption.  This is where the confidence and the credibility of the IT come into play.

IT teams who have been formally trained and have been deploying VMware technology successfully in the past are more effective at virtualizing increasingly more business critical systems and applications and break through skepticism. The ones who have adopted the more advanced VMware features such at SRM, Fault Tolerance, High Availability and SRM tend to have the highest virtualization percentages as they quickly move beyond just consolidating servers into providing better SLAs and disaster recovery capability for mission critical applications.  I will spend more time and posts to talk about this concept as it is one of the biggest lessons we learned from our customers.

Virtualization is much more than server consolidation. It is a transformational technology that allows IT to become nimbler, provide better application SLA (Service Level Agreement) and up-time for mission critical applications, lower their OPEX, shorten time to market for new projects and applications, simplify desktop management and ultimately increase their quality of life

I know that above sounds like a VMware marketing slogan, but it is in fact what we heard from customers and in the next few posts I will give you examples and anecdotes in their own words.

Here is a funny video produced by one of our customer that nicely makes the point:

Sponsorship/Ownership

The second key element of virtualization adoption is sponsorship. In the customers we interviewed, there is a direct and strong correlation between whether the CIO is  involved with the virtualization effort and the degree of virtualization they achieved (and in turn the business value they got in return).

Many virtualization projects start below the radar within the IT department. At this stage it is not even a matter of sponsorship but a matter of ownership. IT virtualizes what they own. They see the advantage, they apply the technology, the enjoy the benefits. They don’t have to ask for permission. As virtualization adoption grows, new levels of sponsorship are required for the journey to move forward.

One of the major inflection point is when IT virtualizes the first business application. I will spend a whole post on this later. The key here is that when IT does that, they have to deal with a different sponsor. The application owner. The person whose job is to deploy and operate a given business application such as Microsoft Exchange or SAP and often their counterpart and stakeholders on the LOB (Line Of Business) side.. This new level of sponsorship requires more sophistication on the part of IT both in term of confidence as well as understanding the different set of issues that application owners care about. They don’t care as much about consolidating servers. They care about how quickly they can deploy a new version of the application, how they can improve the application SLAs and up-time and so on. As IT goes on and virtualizes increasingly more mission critical applications and they realize value that goes way beyond server consolidation, the sponsorship goes all the way to the top of the organization, typically to the CIO.

Customers who have not successfully obtained these increasing levels of sponsorship, have stagnated at low level of virtualization or have moved their journey very slowly.

Value

Value is the third key ingredient of a successful virtualization journey. Customers who have progressed steadily have done three main things related to value:

  1. They tracked value delivered by virtualization projects. Some established key metrics that they reported on the regular basis. Other did it project by project. Others built MBOs for their managers around virtualization targets.  In any event, most of the more successful customers have formally tracked value to be able to get better level of sponsorship and justify new projects (and why not, get a fatter bonus)
  2. They evolved the type of value they tracked over time. This means that as they progressed their journey, they went from tracking mainly hardware cost savings to also account for data center space, power and cooling savings, operational efficiency gains (e.g. faster provisioning), increased application uptime, all the way to desktop support efficiency and security, application life-cycle and quality improvement, and faster time to market for new applications.
  3. They shared and celebrated the value. Customers have shared both outcomes and value delivered by virtualization projects to their management team but also across organizational barriers to spread the word about the benefits of deploying virtualization technology and running business applications in a virtual environment. We have collected all sort of evangelization techniques in our interviews. I will share them on this blog later.

Some customers have actually gone back to previous projects and calculated the value delivered even months past the end of the project to show to themselves and their management the benefit of virtualization and get air cover to scale the effort going forward.

The key point here is that effective virtualization journeys require a strong and credible framework to track value over time. We do want to help our customers doing this and as part of the customer journey project we have enhanced our ROI calculator to enable customers to predict and then measure the business value delivered by virtualization projects.  This enhanced ROI calculator takes into account the different business triggers, the cost of adopting virtualization technology, the time it takes to deploy it over time, the type of assets being virtualized etc. Again, more on this later.

Ignore these Key Elements at Your Own Risk

Customers who have overlooked any of the above elements experienced either a slower journey, are still stuck at lower virtualization percentage or ran into painful setbacks.

Without the right level of competence and experience (which combined give you confidence) you can make technical mistakes which can stall your journey.

If you don’t track success, outcomes and value delivered, you are going to struggle to spread the word and break through potential skepticism.

If you don’t learn how to address the concerns of different type of application owners and stakeholders, you don’t get the right level of sponsorship which will ultimately slow down your journey.

We have seen a combination of all of the above is some of the customers we interviewed and we learned how they recovered from black eyes (it takes time BTW), what tactics they used to evangelize the value of virtualization and the internal cloud within the organization, how they used different layers of the VMware product portfolio to address application owners concerns.

The Adoption Workflow

As you will see in the next few posts, we came up with a model that we believe describes most customer virtualization journeys. For sure, it models the over 30 journeys of the customers we interviewed directly. .

Here I want to double click on the “Adoption” box in the figure above and introduce the workflow that describes an individual virtualization project.

Virtualization Adoption - Workflow

Virtualization Adoption - Workflow

  1. Business Triggers: a project is typically started in response to some sort of business or technical trigger. Good examples are: hardware refresh, operating system refresh, data center move or consolidation, mergers and acquisitions etc.
  2. VMware Functionality Ares: depending on the business trigger, the customer then selects the VMware product area that better responds to that trigger. For example a disaster recovery exposure would be addressed by the deployment of SRM, a desktop management challenge would be addressed by deploying VDI and so on
  3. Assets List: then, one needs to identify what type of assets and applications are being impacted.
  4. Confidence Check: At this point the question becomes: does IT have previous experience virtualizing these type of assets using the required VMware product areas? If not, then training, a proof of concept (POC) or consulting is required.
  5. Obstacles: once the confidence is there, it is a question of addressing obstacles (do we have the right storage solution? are all stake holders comfortable? …),
  6. Best Practices: then applying best practices for the project at stake (in this day and age, we are typically hard pressed to find applications that have not been successfully virtualized by somebody out there)
  7. Outcome+Value Calculation: At the end of the project, one must assess the project outcomes (faster provisioning, better uptime, increased capacity for future growth etc) and calculate the business value delivered by these outcomes
  8. Report, Evangelize, Celebrate: finally the team must celebrate their success and evangelize project outcomes and value delivered across peer organizations and with upper management.

We found that most projects can be modelled this way. The two pictures above call out both the key elements that drive virtualization and the major factors that one has to consider when carrying out a virtualization project.

What is Next

In the next post I will cover the three stages of virtualization as we heard it from our customers and explain how the  dynamics between confidence, sponsorship and value change as the customer virtualization journey progresses over time across the three stages. We will also share the taxonomy we came up with based on our customer interviews to catalog business triggers, product functionality areas, capabilities/outcome, related metrics and the different type of value delivered by virtualization.

until then, ciao

Vittorio

4 Comments | Virtualization journey, vmware | Tagged: | Permalink
Posted by vittorioviarengo

« Previous Entries