The eighth member of our team is joining us December 16. Welcome on board Yves!
Our second team gathering is coming to an end, and we could not get any happier with the outcome. After a fast and furious week, we managed to implement many critical features and fix a ton of bugs. Most importantly, we integrated several core components of the platform that had been developed in isolation from each other up to now. Having the seven of us in the same room for a week with an end-of-week deadline to motivate us was a good thing. Clearly, we’ve exceeded any productivity benchmarks we could have set to ourselves. Today’s demo was a clear success, and we now have a very detailed roadmap on our Pivotal Tracker. If we follow it without adding too many new features along the way, we should have a production-ready version of the platform by Summer’s end. Still a ton of work ahead of us, but we’re starting to see the light at the end of the tunnel. Good stuff…
- 11 months and 18 days
- 110 hours/week for some team members (on average)
- 7 highly motivated developers (scattered across 4 timezones)
- 4 total re-writes of the user interface (5 versions in total)
Earlier today, we shipped STOIC to our first 184 customers.
To be more precise, at 3:43 AM PDT, the last customer had received a notification email indicating that his/her STOIC instance was now ready for use. But guess what? 3:43 AM PDT on Thursday, March 13 2013 was 11:43 PM SST in Pago Pago on Wednesday, March 12 2013. So, technically, we shipped at the originally-promised date. In my 14 years career in this industry, it’s the very first time that my team ships a product on time. I can hardly believe it…
To make things even better, I wasn’t even there. As you can see on this log of last night’s events, I was deep asleep when all this happened. All the hard work was actually being done by Hugues in Singapore and François in France. Altogether, it took us 9 hours to ship, and we went through it without screaming or shouting, and barely any hint of stress. Then, when I could not help much and needed some rest, I transitioned over to my teammates, and they ran through the finish line, on their own. Anyone who has worked with me in the past few years might have a hard time believing that I could delegate the most important pieces of work that we have to get done, but somehow, I managed to find a way to do it, and nothing could make me more proud today…
To be fair, most of the praise goes to Hugues, who not only implemented the automation framework we needed to deploy and upgrade 184 instances on Cloud Foundry, but also had the fortitude to push for a massively distributed architecture that has never been attempted before for a platform like ours. And he did that largely against the informed advice of Pascal, who was legitimately concerned that such an architecture could create massive administration overhead. We still don’t know whether it’s the case or not, but Hugues clearly demonstrated that the setup and upgrade process could be built, because there is no way that we could have manually setup 184 instances in an hour like we did today…
While I’m totally ecstatic to have shipped a product on time for the first time in my career, I am immensely proud that we could do that with the kind of distributed authority that we’ve been trying to establish in the company since Pascal suggested that we should learn from the successful experience of Valve Software. While we still have much to learn about how to scale such an organization, it seems to be working a lot better than anything I’ve done in the past, and it’s definitely a lot more fun.
So, without further ado, a huge congratulations to Hugues for a remarkable piece of work, a huge thanks to François for some pretty boring yet necessary testing and notification work, and a huge thanks to all our customers for giving us the chance to do all this and to try all these new things.
We did it! On time! Awesome!
In case you’re wondering, all the work related to the setup of instances is done by Hugues, who is based in Singapore. Hugues is a gifted developer, and an expert with Cloud Foundry. He is also deep into agile, and an avid singer. Now, here is a cool fact about the guy: when he was living in Silicon Valley, he and Donald Knuth were part of the same choir. Yes, the Donald, of TeX fame… The guy who wrote The Art of Computer Programming…
Go Hugues, go!
Following my recent post on Florian’s work, Pascal half-jokingly objected that he is not yet part of our team, for he has yet to break something. Pascal is right: part of STOIC’s process is to break everything until it’s been fixed so well that breaking it again gets really difficult. So, here you go Florian: try to break something. Our build process, our meta-data, our spreadsheet importer. Something. Anything. Go for it!
Between 1999 and 2003, Jacques, Pascal, and I worked with a really cool developer from Australia: Jim Alateras. Today, Jim signed up with us again. Starting in November, STOIC will have a presence in Melbourne, Australia. Awesome! Awesome! Awesome!
Our CTO is a rather private person, and somehow preferred to fly under the radar for the past few months. But with the release of our new website, the presentation of our team, and the announcement of our first open source projects, we could not keep his identity secret for much longer. So, please let me introduce Pascal Belloncle, one of the most talented engineers in our industry, and a loyal business partner of mine for the past thirteen years. So far, Pascal has been single-handedly implementing the server side of our product, and when we go live, you’ll be amazed to see what a single developer can do when you don’t distract him too much and feed him with good chocolate. Welcome on board Pascal!
PS: Don’t ask him to update his LinkedIn profile, for he could not care less. I know, I tried…
About two years ago, one of our main sources of inspiration passed away. As we prepare ourselves to release our new product, we remember this wonderful man, his family, and Japan. Fond memories of intelligence, passion, and mutual respect.
Last Friday, we conducted an interview for a candidate who might join our development team in China. The meeting took about two hours and a half, with all members of the team participating. It was a very candid gathering, giving the candidate a good idea of how our company is working and whether this is the kind of environment he would like to work in.
During the meeting, we spent a fair amount of time discussing about how decisions get made within our company. Essentially, all decisions must be taken unanimously. At this stage of the game, any question worth discussing should have an actionable answer that everybody can get comfortable with. Therefore, unanimity is the rule.
If discussions cannot reach that point, they get escalated to an executive who can make the final call: Jacques-Alexandre for money-related issues, myself for product-related questions, and our CTO for architecture decisions. But what’s very clear to all of us is that such an escalation demonstrates a failure of our collective decision process, therefore should be avoided whenever possible. Once again, for it to be considered right (or good enough), the right decision should be able to gather the support of everybody involved.
Now, such a process should not be confused with a democratic process. A company is not a democracy. Decisions are not made through votes. If they were, you would end up with products like the Motorola ROKR, which was an absolute disaster. Either our collective decision process works and we quickly reach unanimity, or it does not and we revert to a simpler autocratic process for a particular decision that proved too difficult to make collectively.