CSY R&D Lab Manager
You don't have to go very deep inside the HP 3000 R&D organization to see that attitudes have changed in the past four years. Engineers have accepted a communicator's duties as part of their responsibilities, building relationships with customers to steer development and justify enhancement requests. That philosophical earthquake comes from an epicenter of leadership in Harry Sterling. Celebrating 20 years with HP next month, the R&D chief for the Commerical Systems Division (CSY) has encouraged new behavior from his technical staff - and accomplished it faster than the usual tectonic-plate-shift speed of engineering attitude changes.
The R&D shift ensures that Customer First is more than a marketing slogan, and it has made Sterling a respected manager among the customer base as well as inside CSY labs. Sterling had to cast himself as the prototype for today's connected CSY engineer. He was a hands-on development engineer, migrating Rapid and VPLUS to Native Mode in 1983, then joined the MPE lab in 1986 to manage the MPE/XL Command Interface project and MPE V to MPE/XL migration tools. He assumed the CSY R&D lab leadership the next year, and came to his first Interex conference in 1991, after the brushfire of customer dissatisfaction which burst open a year earlier at the Boston show. Since then he's transformed his engineers' behavior, changing them from technical specifiers to customer conduits who help energize the HP 3000 renaissance. We asked him at the recent Interex conference to explain how this customer focus changes the way CSY's R&D works.
The transformation of the Commerical Systems Division to a customer-focused organization has been one of the sparkplugs of the HP 3000 renaissance. As technical leader for CSY R&D, did you find the renaissance was most profound at the engineering level?
Yes. The management team had to really change the way we think about what we were responsible for. There's a cartoon of a tightrope walker who sees a fire climbing up the pedestal, and he's hesitant to go out. That's what it was like for us. In Boston [in 1990], the customers set fire to our pedestal and we had to move.
For the CSY engineering community in particular, it was very hard. In our culture, that [customer communication] was somebody else's job. We had compartmentalized the whole value chain, and tossed it over the fence to the next person who was responsible. When our customers said “The whole sales model has changed, we're not happy with what's going on, you're not hearing our needs,” our immediate reaction was, “The field has screwed this up. They've got to fix it. Or marketing has the problem.” We had to change philosophically, and realize we're responsible for all of it, whatever it takes. If there's something wrong in the value delivery system, it's our responsibility to fix it.
So how did you affect the philosphy change within the 3000 labs?
We pushed the concept of the team well beyond the traditional functional boundaries. We had to change the way people behaved in the organization. We did it in a very similar to the way you change the behavior of a child: reinforce the positive things, and ignore or be more severe with behaviors that weren't acceptable. Somebody saying “It's not my job” was not an acceptable answer.
We built a lot of positive reinforcement around customer focus, simple things like buttons at departmental meetings. I have a department meeting every Friday, and one of the things we talk about is our customers. I changed the day and the place of the department meeting to symbolize we were doing something different.
I had buttons made that said, “Ask Me About My Customer.” Anybody who'd had contact with the customer and talked about it at the meeting got a button. I used to put a microphone in their faces at the meeting and ask them about their customer. That was negative reinforcement, so I changed the rules to let people talk if they wanted, and if they did they got a button. After three months, everybody talked about their customers, because it's exciting.
People want to know what's going on with the customers. They recognize they have broadened their capabilities and learned more. They know they're more marketable. Frankly, they don't want to go into some of the other HP organizations, where they see it would be a step backwards by taking away that empowerment. It would be a boring technical job.
How did the talk translate into benefits for the customer?
We haven't put processes in place around this new behavior. We've empowered our people to do the right thing. At my last departmental meeting an engineer talked about how she'd called a customer to discuss a Service Request. She didn't understand the SR and realized it was an enhancement request. The customer felt it was a critical defect, and the engineer didn't just want to reclassify it. Together they decided to rewrite the text of the SR and decided it was a defect in the context they described. With the customer's agreement they scaled back the SR to define what the customer really needed. She was able to solve the customer's problem by giving them information on another way to do what they wanted to do. That's never would have happened three years ago. We would have said the SR didn't meet our specifications, it was an enhancement and closed the SR. And that would have been a customer dissatisfier.
Is this closer contact absolute throughout the labs?
Some people are comfortable having one-on-one customer contact, and some aren't but are still a part of the new thinking. One day I was walking in an area where a technical architecture discussion was going on, and someone asked what the customer would think of an idea. Everybody stopped, and someone finally said “I don't know. We better find out.” That's when you know they've gotten the new thinking. The motivation becomes one of solving a customer problem, not of technological achievement.
That kind of input can draw out a development process. What has the impact been on quality of CSY products?
We don't want to come out with something that's unusable just because of internal issues. We used to deliver solutions all the time that weren't complete. Now we say that if a component piece is not part of the solution, then it's no longer a solution and we'll can the whole thing. If a piece is ready, but some of the critical support pieces aren't, we'll delay the whole thing. It gets us into trouble and the customer into trouble if we don't deliver the whole solution.
After being an engineer-run division and a marketing-run division, CSY is now making efforts to be a customer-driven organization. Can five customers who need a product make something happen in HP's development, something HP wouldn't have thought of by itself?
Customers aren't telling us what to build. They're helping us understand their business environments, so we can supply the knowledge and technology jointly with their understanding of the business problem to come up with a solution that works together.
So that problem becomes the focus, rather than engineering your solution?
The kinds of questions I ask now address whether the engineers understand the core problem they're trying to solve. They used to revolve around the technology. Once they understand the problem, it becomes an engineering problem, and they're good at solving those.
How does this process change those situations where development of a solution costs more than estimated?
We go back to customers and ask them if they're willing to pay. We disclose to them what the alternatives are, as we did for IMAGE/SQL and a higher support fee along with it. When the timing is more complicated than we orginally thought, we cancel solutions. The customers we work with are aware that it's a possibility, that it wouldn't make sense to continue. Even in those cases where we're cancelled solutions, because we know there's a problem there, we'll look for other ways to solve it.
Customer visits are becoming a more regular part of your development process. How is the concept of taking CSY into the field impacting the rest of your operations?
I visit HP's response center sites whenever I'm travelling. I was in Atlanta six months ago for a lunch meeting, updating the engineers on what we're working on. At the end they said they'd never had an R&D manager visit them, and thanked me.
Customers look to HP first for solutions, but many times they can be had easier from a third party has engineered such as C++. How has the Not Invented Here syndrome fared?
We're going further than we used to. Support is a key issue for most customers. We're also trying to do a better job of understanding why a customer doesn't want to use an existing solution, and wants us to duplicate it - and in some cases put a business partner out of business. If the issue is that a customer only wants to call one person for support, we'll fix that part of the problem. We can focus our energy on figuring out a process to give the customer a single point of contact. We'll treat that business partner as an extension to our R&D organization, rather than stomping on their product by duplicating what they're done.
Complete duplication looks like something you want to avoid, but what's the reasoning behind offering lightweight versions of functionality like sendmail or network printing?
For the low-end and midrange kind of customer, some of these solutions aren't meeting their needs. They want that lightweight version of what's there. The first thing we do is attempt to work with the third party, to see if they can create the lightweight version like FileNet did.
We also recognize we can't do everything, and our relationships with our third party software suppliers are critical to our success. We need to treat them like would an internal part of HP. Some of the pieces in an open system world will be provided by other vendors.
What can the R&D customer focus do to spark more HP 3000 solutions from these third parties?
We have to lift ourselves above the technology, go beyond the platform and ask what's the right thing for the customer. The right thing in one case was making sure SAP running on a Unix system co-exists really well with the 3000. Our investment ought to be linking those two platforms together, so they can manage better in a heterogenous environment. Getting above the platform view is another example of how things are different; five years ago we would have focussed all our energy on the 3000, and anything beyond it wouldn't have been our responsibility.
So how does the R&D group help push this customer focus out into other HP divisions?
We talked a few weeks ago to the Professional Services Organization management about what we've done. We focus on the behavior change that has to occur, the way people think. We gave them signs of how to know when they were successful.
Why do you think you've been successful with a customer focus for R&D? Is it because of the strong investment in the HP 3000 means less distractions than coming through an open systems environment? Could your customer relationship focus have gained such a good reputation through customers with less vendor dedication, like those using Unix?
I think a relationship is critical to both R&D as well as the customer. If you don't have a relationship with your customer, then you don't have a competitive advantage. The competitive advantage of the future is building a relationship. A customer wants to know that we care, and when they have a problem we'll be there. The way people get a sense of trust is through communication. Everybody in HP has to take the responsibility for saying that's part of their job - making sure we are communicating.