Click here for HP Sponsor Message

NewsWire Q&A

Harry Sterling
Staying Ready to Grow a Supplement Market

Harry Sterling has had an interesting first year as HP 3000 division general manager. Within a few months after taking his job he went to the battlements over HP's commitment to the HP 3000, hearing out the "Proposition 3000" debate at last year's IPROF meeting about embracing Merced chip technology and 64-bit MPE for the 3000. Sterling spent much of his first year answering questions about how the HP 3000 was going to keep up with the Jones in NT and HP-UX, giving an impassioned speech at HP World that promised answers to all questions about the 3000's growth path in a strategic TV broadcast this spring. That telecast left the question of IA-64 support unresolved, but Sterling's leadership provided a clear message on building on the 3000's success even while those concerns flew in the weekly trade press. His division finished at almost 130 percent of sales quota for the fiscal year he was general manager, and posted another plus-quota quarter to start fiscal 1997. In this first of a two-part interview, we checked back in with him at this year's IPROF to see how he plans to keep the HP 3000 as far ahead of customer needs as his sales have been above quota.

How do you expect to step on board the IA-64 train if HP 3000 customers need it? What everybody heard in January was that you haven't quite said yes or no at this point.

In terms of the investment we need to make for the 3000, that's true. A lot of what we are doing are things we'd have to do anyway along the way to get to where we're going. For example, the larger than 4-Gb files, the implementation of the new RISC chips cause changes that we'd have to make that are consistent with the direction we'd need to go anyway with a new architecture.

Moving to 64-bit would be something that we'd need to do, and we're evaluating how we're going to take advantage of 64-bits with the 3000 platform. So whatever we do along that way we're driven by customer need. We're making sure that it's consistent with the direction of the new architecture.

We have had our key CSY architects involved in the architecture council right from the beginning, so we're fully aware of what the new architecture is and how it functions. Within my lab -- in order to better understand the architecture as well as giving my engineers some opportunities to develop some new skills and work on some technologies -- we were responsible for porting the Intel performance tools to PA-RISC, so we understand it from that perspective.

We have since ported them to an emulator for the new architecture, and are responsible for managing those performance tests and architecture test suites. So that's something that we did within our team. We were funded by the Systems Technology Group to do that work. It was one of those things that was a single task. You wouldn't hire permanent staff to do it, and [STG GM] Rich Sevcik was looking for somebody who wanted to do this. We did it as a way of giving our engineers an opportunity to learn.

So we're very familiar with the architecture, what it can do and where it's going. I think that's given us a way of staying plugged into that whole thing. I attend the monthly review meetings. Mark Calomeni, who was the section manager in my lab and is kind of focused on the technology areas, runs our architecture council, attends all of the business and technical reviews. So we are plugged into that whole activity.

We have a CSY architecture council, which is a collection of our architects, and that's plugged into the STG architecture council. It's made up of engineers from both HP and Intel. I can't say too much more about how that functions because of the arrangements we have with Intel.

Well, certainly engineers move on to new positions, and some of those people are in the new architecture work. Whether they actually come back into CSY, that would be their own career choice. But as I said, we are plugged into that, so that within our own organization we have knowledge of the new architecture -- so we would not be dependent on people having to come back as we move forward, if and when we do this.

No, actually, and I'll tell you why. I think HP has a very good business model in place in the way we define certain business areas, and it's not always clear from the external perspective of how that all works. We effectively have product line divisions formed around what we consider to be business segments, and each of those product lines is expected to function based on certain business fundamentals, including some key operating profit objectives. It's HP's way of forcing us to track our costs and to make sure that we're making the right level of investment consistent with the return on that investment.

From a business point of view I think it's a very good model. One of the things that customers don't always understand is that the support revenue funds the support structure and the support business, which is a separate business -- just as though it were an Arthur Andersen consulting company or a support services organization. That's what our support function is. Their support revenue sales channel is through that function. They track their costs within that business and the return on their investments -- which is significant in terms of new tools, new technologies, the facilities, the training of their people--that whole infrastructure providing support services 24 hours a day, seven days a week around the clock around the world is a significant investment, and so HP has chosen to look at that as a business investment, expecting the appropriate return.

So the support revenue goes into that organization to support the 3000 support staff's tools for technologies. I think it's a very good model. It forces the support organization to be competitive with support contracts, to be competitive with cost structures. It forces the product divisions, us, to have high-quality products -- because if they funded us to fix our own defects, then we would be very sloppy about the quality of the software that we delivered.

The small amount of questionable funding would be what I would consider ongoing and minor enhancements that we do. This is an expectation that customers have as part of the support agreement. Our expectation is that what you get for that support agreement is bug fixes, minor enhancements and new upgraded versions of the operating system.

Now, the driver for us in the operating system perspective is for us to be able to sell the hardware platforms from CSY's perspective, which is how we get our revenue. I think that mixing those two things would make our business model very complex, very difficult to track true costs.

I guess the question I need to put back to the customers is what's the motivation for doing this? They want more. Let's not play games with the support revenue to try to get more. I'm open to forums within the customer community to fund special projects, if that's something they need. Maybe that's a way in which Interex or some of the SIGs could collectively gather customers who are interested in a certain direction -- one that we have deemed unimportant in terms of our prioritization activity, which is frankly driven by our ability to remain competitive and to continue to sell new hardware to the majority of our customers, which gives us the maximum revenue.

I am running a business. If I don't get a proper return, I have to reduce my investment. The other part about the support revenue model that I think is wrong is that everybody is paying a tax for something they may not need.

Why not have the people who want some specific thing collectively gather a -- birds of a feather comes to mind -- group of people who want this and are willing to fund it, if it's that important to them?

I would fund it through contractors like Stan Sieler -- people who are third-party partners. It gives them additional revenue to continue to invest in the platform while we're focused on the things that are most critical, things that we believe will give us the maximum return. Because if we don't make a profit and get the maximum return on our investment, then that hurts us further down the line in terms of our ability to continue to invest.

If you look at it from an emotional point-of-view, it looks like a way in which the customers could get us more money, but it really distorts HP's business models. And I think it causes us, for example, to potentially lose an opportunity in terms of doing something that doesn't pay the return. So if I take five engineers to work on something that a small number of our customers think is really important -- but it doesn't give us the maximum return overall for our business that I could get if I used those five people for something else -- that's lost opportunity. Then it hurts us overall in the business.

Now if these things could be done as a supplemental activity, not causing me to take my skilled people off the critical things, then I'm all for it. But don't give me more money that causes me to work on things that are not going to give me maximum return.

Well, my architects could certainly participate, but I have complete confidence in Allegro [Consulting, where Stan Sieler is a partner], for example, and their ability to do pretty sophisticated things. And so that's how I would use that money.

My perspective is that was the funding to get that initial activity out, and that funding now comes into CSY.

Again, I look at it as maximum return on the investment. How can I use my overall R&D dollars to get maximum return? I believe that is going to ensure the longevity for our customers. I mean, if I simply took my resources and did what everybody would like us to do, and didn't do some of those strategic things, then our life potentially would be shorter than it should be. Doing those things I think are going to cause us to be able to continue to get upgrades, to support new platforms, to support new peripherals, to continue to ship hardware -- that's the way that I drive my business point.

We are seeing the money, but it doesn't necessarily all go into IMAGE/SQL. If I looked at it just from the IMAGE point of view, a lot of investments that I'm making -- for example, the performance investigation that we're doing right now -- when we figure out what the next big incremental investment in software to improve performance, that's going to help the IMAGE users. So, how do you carve out a piece of the dollars and say, "I can only use it for IMAGE." What does that mean? I have to look at the whole environment and say: "What's the best investment I can make for the whole environment to continue to support our customers the best we can?"

Right. I mean, the lab is the single organization we have. We don't carve things up -- we have project teams, but we don't have things carved up such that we have one group of people that don't have enough work to do and another group of people that are overburdened. We have a very flexible organization. And we assign people to solutions based on the need, based on the solution teams.

And we have a core set of people in each of the four areas where we know that team can maintain the expertise. But for the most part, the organization is very flexible.

No. I'd rather have the other model, where if you really want this funded, then don't force me to use my resources in a way that may not be the best return on the investment. I'm not saying IMAGE/SQL was the wrong thing to do.

And we've come a long ways in the way we do our business planning than we were then. At that point in time we had four different labs within CSY, we've now collapsed into one large lab. This gives us a lot more flexibility in focusing on whatever the next thing is that we need to do.

I can remember situations where we had a file system team that was just always overloaded, and we had other teams sitting over here thinking about, "What could we do next that would be fun to work on," because there really wasn't a demand for their particular area. That's not the right model to get the most out of your investment. So I think the models we use now with the solution teams is much better -- it gives us a lot more flexibility.

I'd like to be able to think about one of the overall investments that gives us the best return, whether or not we need to do the work ourselves, whether we can contract it out. We contract out a lot of work. Because if we don't have to do it, I don't want to use my highly-skilled engineers to work on things that somebody else can do. I really like working with third-party partners if they can provide the solution, and we can both win. They get some investment opportunity -- or some financial opportunities or revenue opportunities -- and we get some help in doing what we need to do. That's the right thing to do.

If there was a solution out there, the last thing I want to do is to duplicate that activity and take out revenue opportunity away from a partner. I mean, that's not a good business model.

Now the customers sometimes may think, "Well, we get it free from HP because it's under FOS." I absolutely know that in some cases if I try to charge for an option, there'd be rebellion. But if a small software company charges for an option, then people are willing to pay for it. Well, hey, I look at my overall investment opportunity. I've got to get a return on that investment. I hate to say this, but some of our customers aren't willing to pay for the value that we're providing. They want it free. And so that model doesn't work any more.

Frankly, sometimes with these smaller enhancements and smaller things that are not strategically important to us -- where we look at it and say, "Hey, this is going to be burning an engineer for a year for which we get no return on that investment" -- it's better for us to work with a third party. Let them have a little optional software product, and the customers who really need it can buy it from them. That model works very well. It's kind of the model for open systems, unfortunately. Customers would like to buy everything from HP, but hey, that's not the environment we're in. If we try to keep that old model, it limits our ability to remain competitive.

No. I think there's still tremendous leverage that we gain by being a part of HP. I mean just think about what we'd have to put in place, just the worldwide support structure that we have to duplicate or contract out to someone else who would then say, "Well, you're not supporting it yourself." We want to have linkage into the R&D organization; we want to have linkage into the people who are actually writing the product. We want it to be all the same vendor-provided solution. So just the HP name, what it stands for, has a big impact, particularly to new customers. I mean we still have a fair number of new customers, particularly on the high end. If we were our own separate little company, I'm not sure we would still be as attractive to some of the Fortune 500 companies as we are having the HP name.

I think that as much as I hate the corporate tax I get, when I really look at what I'm getting for it -- all the architecture work that goes on outside of our division that we leverage, all the chip technologies, all of that kind of information -- we'd have to provide a lot of that on our own. And so I'd have to deviate a lot of resources to doing things that wouldn't allow us to be as productive.

Once you bring all of those things together, it adds complexity to communication decision-making. Now I don't have to worry about it. I have to stay plugged into the support organization; I have to review their plans on an annual basis and make sure our customers are getting the proper level of support, but frankly I don't have to worry about, "Well, how do we deal with 24-hour-a-day seven-day support?" They take care of that stuff, and if I had to have that kind of infrastructure in place to do that, it would divert our attention.

Since I've been in the job, I've gone through a cycle of business planning. We're going into our second one now. We update our business plans, so I'm into my second iteration on that. We completed one set of solutions and started into a new set of solutions, and we have all the funding in place to move forward with those. I'd have to say yes, it is mine. I have made changes within the division about the structure of some of our meetings, the frequencies of our meetings, trying to push on the bureaucracy to simplify the decision-making process. So there has been change. Nothing dramatic. I haven't reorganized the whole place, for example. I think I've made a mark, so to speak.

Copyright 1997, The 3000 NewsWire. All rights reserved.