In the trenches with...Gary Whizin of MySQL
In an insightful second installment of the "In the trenches" series, I talk with Gary Whizin of MySQL. He talks about working remotely and how the distributed development process of open source/MySQL first rattled him, then grew on him, then became him.
First off, I'm changing the title of the series to "In the trenches with..." because I'm finding that the best people are often not keen to sing praises to themselves (i.e., "Unsung heroes"). At any rate, while these people are, in fact, the heroes of open source, the series is designed to glean their expertise and provide a "trenches" view of commercial open source.
Hence, a new name.
Nowhere is super-capable humility in more abundance than MySQL. I love that company. I've yet to meet anyone there that I wouldn't enjoy sitting next to on a long plane ride. Mostly because they're somewhat quiet, and I hate talking to people on planes. But... :-)
I asked Zack Urlocker to suggest an "unsung hero" at MySQL and he suggested I chat with Gary Whizin, senior director of Engineering. (He suggested a few others, as well, which I hope will find their way to this series, as well.) Gary chafed a bit (he was insistent that his team, and not he, does all of the real work), but we eventually wrangled this response out of him:
Name, company, title, and what you actually do
Gary Whizin. Officially, I'm Senior Director of Engineering for the MySQL Enterprise Tools group. In reality, I run projects and manage a team like a baseball manager: I help figure out who works on which tasks; I help define our milestones and ensure we're on time; but then I try to let everyone have as much fun as possible because life is short and that's the best way to win anyway. I also ask oodles of "dumb manager" questions to make sure we're being as smart as possible, have the right priorities and are talking to each other.
Then I try to stay out of the way and admire everyone's work.
Do you work remotely or in an office with co-workers?
I almost always work from home. Our corporate office is 40 minutes north of my house, and I try to go in every month or so. Frankly, I work there so rarely that I haven't yet figured out how to be productive when I go in.
If you've had a similar role in a proprietary software company, how does your current role compare? Similarities? Differences?
My daily work activities have been remarkably similar to what I did in a comparable role at Borland; however, we've recently given birth to a very cool open source project (MySQL Proxy). So I'm now watching in fascination as perfect strangers do our work with us.
Is that a change from my past experience? Definitely. We still listen and think of things to do. We still ask whether we're building something because it interests us, or because it's what our customers are asking for, or because it's what they really need, or because it would be popular. And we still do the project management tango of balancing: time-to-market, risk, functionality, passion and our own quality of life. However, we also consider whether something is for the Community, the paying customer or both. It affects how early we release something and who works on it.
Until recently, all of our Enterprise Tools projects were structured according to the org chart. Sure, we borrow brain power from other engineering teams and from sharp people in Professional Services, but that's only an occasional hobby for them. If you were working on a MySQL Enterprise project everyday, you were on our team, or you were the dedicated person in your group assigned to work on our projects.
In contrast, although our MySQL Proxy project is led by Jan Kneschke from our team, it's actually worked on by anyone who takes an interest in it. The difference is pretty dramatic: a project like this quickly takes on a life of its own and, early on, there are people outside the team or outside the company who may know more about an implementation detail than a close colleague. Eventually, we sync up and integrate the two worlds in our MySQL Enterprise offerings.
How familiar were you with open source before you joined your current company?
I wasn't. It sounded Arthurian to me, and I didn't understand how a virtual network of people with day jobs could start, finish and maintain serious software engineering projects. I didn't realize how much commercial commitment and structure there is in the open source world. I assumed there would be problems with quality and longevity, but in fact it is the other way around. We've all witnessed great people build great software while the company around them was fumbling and crumbling. This, however, never led me to question the viability of proprietary software development. In hindsight, it should have been obvious that open source software engineering would work because great people self-select, nothing is a trade secret, and the world is a very big place.
Why did you join an open source vendor?
The open source aspect was intriguing but not the determining factor. There are very good business and technology people here and millions of happy users, and that's why I joined. However, to be honest, I was tricked into joining. I was enjoying a nice sabbatical when Zack asked me for advice "as a favor." He had me sit through a week of technical training to get up to speed and and then told me about various engineering initiatives that needed organizing. As I warmed to the task, he pointed out that my teenagers were pretty much leaving the nest anyway and why didn't I join and try to be of some use to the world again?
I had other opportunities, but where else can you start with 11 million dedicated users? There's a buzz at MySQL that reminds me of the glory days of Apple or the early days at Borland. Everyone feels that way, I think, and it shows the minute you start meeting people here.
How long did it take you to adjust to an open source operational mode?
The company culture is incredibly open. I don't know whether that's because of our open source roots or because we're founded by Finns and Swedes. At any rate, we don't waste time or energy worrying about guarding trade secrets. Customers are invited to every offsite meeting. Brutally honest, constructive criticism is encouraged and self-critique is common. It's also completely understood that smart people will make mistakes "...as long as they're new mistakes," as our CEO likes to say. It's a great way to work, but it took me a few quarters to see that the openness here is real.
I've also been surprised about how who has the most insightful ideas about open source vs. proprietary demarcation. I thought it might be a religious issue, but the people with the most open source credentials are often the ones with the clearest thinking about the commercial side of our business. The open source model is what makes our business disruptive and that's incredibly fun to be a part of.
Frankly, the biggest adjustment has been working in a "virtual company." I work closely with people in five timezones. Someone is always about to grab a meal while someone else is ready to put their kids to bed. I can't decide whether it's the most productive arrangement in the world or punishment for past misdeeds. Anyway, leading a distributed team is by far the biggest adjustment I have to make. In almost every other regard, what we do every day would be recognizable by any software engineer.
What do you think open source companies could learn from proprietary vendors?
Deadlines work. ;)
See. I told you so. The MySQL people are fantastic. And I continue to use MySQL as the model for exquisitely executed corporate distribution. Here's a company for whom the most important infrastructure is broadband and airports. And yet it works.