OK Labs Story (3): The Engineers

We had a world-class engineering team, by any definition. Except for one or two we hired from outside, the complete team that spun out of NICTA on 1 January 2007 consisted of my former students (and Carl, who never was a student at UNSW but had worked with us as an engineer since the early days of NICTA). Most had years of experience hacking microkernel code, and all had an excellent understanding of what makes a microkernel tick, and how you build systems on top of L4. Each could have doubled or tripled their salary by moving to Silicon Valley. They also had grown up working in a tight-knit team, so personnel-wise we were in good shape.

Before we could actually spin out, a (to me) unexpected hurdle arose: the contract negotiations. Steve took a very hard-line approach with the employment contracts. While most high-tech startups tend to provide fairly liberal conditions, what Steve offered was generally the legal minimum. In addition there were very broad and severe non-compete clauses (extending for a full year after leaving the company). While our legal advice was that this was almost certainly unenforceable in NSW, Steve insisted on them anyway.

The result was a staff revolt. About half of the staff refused to sign the contracts in the offered form, some making extensive changes. What followed was a lengthy (4 weeks or so) period of to-ing and fro-ing until we had a contract people were willing to sign. The end effect was that the company started on a sour note. I have to accept some of the blame here, as the original contract didn’t feel right to me, not the way I wanted to treat my students. But, again, I was inexperienced, didn’t trust my instincts in this unfamiliar territory, and trusted Steve to know what he was doing. Clearly a misjudgment on my side, and one I regret to this day.

In the end, Chuck, one of the A Team, decided not to join OK Labs, but instead moved to the Valley to join the Core OS Team at Apple, where he still works happily. At least he didn’t bear any grudge against me, we’re still good friends and meet up for a beer or three whenever I’ve got spare time in SF.

Not so for two others, Alex and Hal, who did sign on but never recovered from the original confrontation. They left about a year later, triggered by another poor handling of a situation by Steve: he had forgotten to perform a stock split before assigning stock options to staff, with the result that they got 2.5 times the percentage they were meant to get. Instead of saying “sorry, guys, we stuffed up” he tried to sell the correction as an improvement to staff, with a mail starting “good news! the price of your stock options has been reduced”. Not a smart way to treat grown-up engineers.

This created more bad blood. And, while I left these management issues in Steve’s hand (bad call, I know!) staff saw both of us as “management”. And it’s safe to say most staff were there primarily there because of me, and saw this as a betrayal of the trust they had in me. This was particularly the case with Alex and Hal, the two who left after a year. Hal hasn’t spoken a word to me since. It was my advanced OS course which had brought him to UNSW (as a postgraduate coursework student), so this hurts and saddens me.

My takeaway: If something seems wrong, do something, familiar territory or not. I should have known that, of course. One of the challenges was that I’m used to be able to trust my instincts, but this was an unfamiliar environment where I didn’t feel I could trust them, and Steve did a convincing show of knowing what he was doing. He also turned any doubt immediately into a personal trust issue, a great way to prevent any frank and open discussion. As I learned over the years, this was symptomatic: he would never admit to any mistake, and the mere suggestion that his approach wasn’t good would be seen as betrayal. The exact opposite to how I’m used to running things: frank and open discussions and looking for consensus.

After the bad start things improved quickly, and morale in the engineering team was very good once most people didn’t have to deal with Steve directly. Steve appointed Benno as VP Engineering, which helped to create that distance. Benno had been my star student, one of the most experienced in the team, despite his young age. He had proven himself in the early Qualcomm project, and is generally one of the sharpest people I know. Making him VP Engineering (rather than getting an experienced manager from outside) was a good move: Benno had more or less grown into the role already and did an excellent job on it. He is a real leader, respected by his peers, absorbed a lot about software processes, and also was a visionary Chief Architect.

We had excellent engineers, and a VP Engineering in charge who, despite his youth, provided strong leadership. The team achieved many amazing feats, generally delivering high-quality software very quickly. One of the most satisfying comment came from the Motorola engineer responsible for the virtualised phone project. He said “there were no bugs!” with the look on his face of someone who for the first time enters a Tardis and sees that it’s bigger inside. And we got consistently glowing feedback from customers after some of our engineers visited them, they never failed to impress through their insight and professionalism.

So in engineering we clearly had what it takes to be successful. All we needed was a plan and leadership to execute it, the engineers would build whatever was required.