Today I took the train out to Long Island to meet up with our New York sales team for a visit with a prospective customer. You never know with an initial meeting, but this one was great. I thought I’d share a bit about what made these guys so excited which is the same stuff that gets me excited about what we’re doing at Delphix.
First though, there are some engineers who have never spoken with a customer. There are some engineering organizations in which requirements are collected from customers, correlated by product managers, handed to engineering managers, and given to engineers. It’s a fine workflow, but this needs to be balanced against engineers engaging directly with customers, hearing their issues, and brainstorming solutions technologist to technologist. Engineers talking to a small number of customers may miss broad trends or fail to connect certain dots, but it’s a complementary activity and part of being a holistic engineer.
I’ve heard software engineers groan that the right technical decision was trumped by business concerns. Those people might be good engineers, but they aren’t great ones. Engineering can’t stop at the boundaries of software; it must necessarily consider the whole ecosystem of the product and the company. Yes, we might not have architected the feature this way if we didn’t have legacy customers support, but we do (and we should be happy for it). (And, of course, this logic can be taken to the other extreme with equally bad results.) This doesn’t mean that a great engineer collects all data first hand, but the whole system must be considered, and walking into a customer’s office from time to time is a reality check.
In today’s meeting, the customer was learning about Delphix for the first time. And they got it right away. As with many enterprises, they have a initiative around virtualization to enable more self-service and more empowerment of their developers. The data in their relational databases is a big anchor weighing down those efforts; the time and effort required to copy and provision databases is a huge drag. Smart guys, they oscillated between how Delphix works — a super-smart, database-optimized storage gateway — and what Delphix does — virtualizing their Oracle databases, bringing the agility and cost-savings of other virtualization technologies. And the slide-ware made real through a demo of the product GUI elicited an terse expression of comprehension: “That’s cool.”
And maybe the best reason for engineers to get into the field is to witness customers who get how cool the product is.
7 Responses
One will never be a true engineer without holistic understanding of the customers’ needs and wants. Never.
Product management, on the other hand, is completely superfluous and not only does it not add any value, it detracts from the overall effort.
Practice has proved that management can successfully be cut out from the entire ecosystem with no ill effects.
For an engineer to make the correct choices, he must practice genchi genbutsu – “go and see”, every step of the way.
How do the customers use the product? What do they want in it? What does a day in customer’s life using the product look like? An engineer should experience this first hand, on a regular basis; in fact, I firmly believe, based on experience, that it should comprise 50% of the engineer’s work!
Same for support: let customers talk to developers directly, so that the developer himself can experience where the pain is. They will be more motivated and focused to enhance and fix the product that way.
Well I pretty strongly disagree with the condemnation of product management and management in general as superfluous. It’s easy for a strong engineering culture to hold low opinions of these other roles in organizations where those roles aren’t filled with top notch people, but great product managers, managers, and support people definitely exist and do their jobs better than a great engineer would. I agree that engineers should experience all aspects of the product, but, for example, I’m sure glad to have David, Don, and Fay supporting our customers — they have a breadth of experience that wouldn’t come from doing the job part time.
Ivory tower ftw! Customers are unnecessary baggage 🙁
#oraclehateshumans
Another confusing comment. Perhaps I should have mentioned that this practice was taught to me at Sun (now Oracle). I’d credit Bryan Cantrill and Mike Shapiro for first pushing me into the field; I’m not sure if it started with them, but it was something engineers did in the kernel group and an important lesson that we brought to Fishworks and beyond.
Glad to see the same practice being applied elsewhere. Some of the best customer conversations I’ve had involved top product managers, sales, senior support and product development all with the customer together.
Direct engineeering-customer dialogs work best when the discussion is about unsolved problems, as opposed to feature wish-lists. Those wish-lists are usually preconceived notions about about how problem solutions should be solved. Sometimes the desired feature is the right solution, sometimes not.
The worst product managers are those that collect those wish-lists without ever attempting to understand the underlying unsolved problems. 😉
“The worst product managers are those that collect those wish-lists without ever attempting to understand the underlying unsolved problems.”
Which are 99.99% of people working in marketing and management.
Marketing is not “just another job”, it is truly an art; and just like there are very few great painters and composers in the history of this world, so too are there very few marketing people who really understand technology and yet have a talent for marketing.
It is high time for a new breed of engineers, the ones with the management and marketing talent, so that management and marketing can be completely cut out of the loop.
Oh wait, that already exists: it is called an entrepreneur.