End-to-end Ownership: From Bug Fixes to Sales Pitches

"Are you interested in product management or development?" I was often asked this question when I interviewed for engineering positions in college. The conventional wisdom was that product managers enjoyed writing specifications to connect implementation details with business needs, while developers preferred to solely churn out code.

As a rising college graduate, I was seeking development positions, since I didn't have much experience with product management. However, I never understood why these roles needed to be so separate.

Jordan meeting on Google Hangout with our Boston office, working alongside Adam Leventhal, CTO, and fellow Brown grad, Chris Siden.[/caption] When I applied to Delphix, I was pleasantly surprised to find there was no such distinction in engineering here.

The VP of Engineering, Eric Schrock, explained to me early on that one of the hallmarks of Delphix engineering culture was "end-to-end ownership." What does this mean exactly? Delphix expects engineers to engage in the entire lifecycle of a feature. Engineers are encouraged to survey business needs and write specifications for missing or subpar features.

"End-to-end ownership" extends past when the feature has been specified and implemented: Delphix engineers maintain their feature after release by fixing bugs and engaging with customers to gather feedback for future improvements. As product feature "owners," engineers are also responsible for mentoring other engineers so they can contribute to the implementation and expand on the feature.

As a new hire straight out of college, when I joined Delphix, my manager suggested I work on the Application Data feature (AppData). I immediately began to understand "end-to-end ownership." AppData's current owner started ramping me up by assigning me bugs to fix and feature specifications to read.

After only a couple weeks, I began to see obvious AppData feature gaps and mocked up improvements I could build in the future. I started writing specifications for these improvements with titles like "AppData as a First-Class Citizen in the Delphix Engine," and I circulated them amongst my teammates for review.

After only a couple months at Delphix, I started implementing these ideas. I also became half-owner of the AppData email alias and took ownership of incoming bugs. As the feature continues to gain traction with customers, I take on more responsibility outside of development.

For example, I recently spoke with four large, corporate customers who were interested in purchasing AppData. I debugged AppData-related issues on their machines and helped sell the feature's value to their DBAs and CTOs. I furiously took notes on my experiences at customer sites so I could remember where the GUI confused users or the implementation fell short of customer expectations.

These meetings increased my bug queue and also inspired a lot of new ideas. Now, I'm also working on recruiting more people onto the AppData team, so we can build AppData better and faster.

I've only worked at Delphix for nine months, but the promise of "end-to-end ownership" has already rung true. I am amazed by the amount of responsibility and customer contact I've been able to take on, and it has been incredibly fulfilling to explain to DBAs that AppData means full, real copies of their applications can be provisioned with almost no storage or time overhead.

Satisfaction really sets in when I have to explain AppData a second time because DBAs think my first explanation was too good to be true.