My name is Ismael Chang Ghalimi. I fight against software illiteracy. I am a stoic, and this blog is my agora.

Second team gathering

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…

What it took to ship a first beta

  • 11 months and 18 days
  • 110 hours/week for some team members (on average)
  • 7 highly motivated developers (scattered across 4 timezones)
  • 76 JavaScript libraries (give or take a handful)
  • 4 total re-writes of the user interface (5 versions in total)

We shipped, on time!

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!

Hugues of Singapore

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!

What it takes to be part of our team

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!

Welcome Jim Alateras

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!

Welcome Pascal

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…

How we make decisions

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.

At the end of the meeting, we all debriefed, concluded that we really liked him, and decided to move forward to the next step in the recruiting process, which is a technical test. The test will consist in packaging a piece of JavaScript code (the moment.js library) and invoking it from a conventional Excel spreadsheet. The quality of the packaging will define whether the candidate has the right technical skills for what we need.

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.

Management by blogging around

Hewlett-Packard pioneered the idea of management by wandering around. At Sutoiku (another company based in Palo Alto), we’re discovering the virtues of management by blogging around. We have no idea whether any other company did that before we did, but for us, it seems to be working.

We just tagged all 300 posts of this blog, which were written in the span of 85 days. That’s an average of 3.5 posts a day if you include week-end days, and 5 posts a days if you just include working days. In other words, we’re dumping some thoughts every couple of hours, for the whole world to see.

Most people could not care less about what we’re writing here, and we can’t blame them for that, for the prose is rather convoluted, and the topics usually arcane. But a few people do care, and those are the people we really care about. They fall into two buckets:

  • Ourselves
  • Our community

For ourselves, this blog serves as a log of our work (Cf. Blog as a log). For the community, it’s a way to engage at an early stage while we’re still operating under stealth mode, to gather early feedback, and to foster a spirit of participation. But we’re starting to realize that it goes far beyond that.

In a company, and especially one building software products for which creativity is essential, communication is everything. But communication is difficult, and meetings only take you so far (Cf. Meetings). One of the problems with meetings is that they’re synchronous, meaning that all attendees have to be present at the same time, and ideally at the same place (no amount of technology will ever replace face-to-face interactions). Unfortunately, for creative people, the best thinking usually occurs asynchronously, outside of meetings. For them, a blog of the kind we’re experimenting with can be very helpful.

Here is an example of how it works: for the past couple of days, we’ve had quite a few discussions internally about whether we should adopt the kind of flat organization that has made a company like Valve so successful. At some point, I summarized our thoughts in a blog post, which allowed me to clarify a few items and identify some issues. All collaborators in the company read the blog post, at their own pace, and gave it some thoughts. Then, a few came back to me with some ideas and suggestions. In parallel, members of our growing community did the same, and now I’m in a much better position to make a decision as to whether such an unusual organization would work for us or not, and what the consequences would be. And all it took was a couple of blog posts and a few informal discussions over lunch, coffee, or email, during the course of three or four days.

As our company and community are growing, the level of participation through the blog is increasing, and the blog is covering more and more aspects of our business (Cf. Tags). This, in turn, creates a fantastic archive for the business, allowing us to track our progress (Cf. Weekly Goals) and to facilitate the on-boarding of future employees. In fact, we make it a requirement for any applicant to read every single post of our blog before their first interview with us.

By using a public blog instead of an intranet or a private blogging platform (think Jive or Yammer), we blur the line between inside and outside, between company and community. And while there are some risks from a confidentiality standpoint, the benefits we reap out of such an open communication model clearly surpass them.

We’re also finding that communicating that way makes it a lot easier to collaborate with remote workers and to extend the Sutoiku experience beyond the walls of our office. For example, instead of hanging a picture on a wall, we push artistic posts on the blog, allowing everybody to enjoy them.

Clearly, we’re still in the early days of our experiment, and I’m sure that we’ll find that a few things are not working. We’re also bound to make some mistakes, especially when it comes to trade secrets or confidentiality agreements that we sign with customers and partners. But we will learn from them and invent a better way of managing a company along the way.

Thanks for participating. None of this would be possible without you!

UPDATE: Someone coined the term back in 2005.

Welcome François

It’s official: François Beaufils is joining Sutoiku as head of Sutoiku France as soon as he completes his internship and heads back to Basse Normandie, sometime in the middle of July.

François is a very talented software engineer, extremely hard working, and gifted with a great sense of humour only matched by excellent musical tastes. Most importantly, his personal ethics are of the kind that are harder and harder to find in Silicon Valley.

François built most of our query builder and will continue developing awesome pieces of user interface when he is back in France, while sourcing young engineers right out of college, train them for a year or two, then send them off to California or China. This will help us build a strong corporate culture across three continents, with minimal overhead.

Welcome on board François, it’s great to have you with us.