My name is Ismael Chang Ghalimi. I build the STOIC platform. I am a stoic, and this blog is my agora.

Statistitics

We’re currently interviewing a candidate who might join our team. As part of our standard interview process, every single member of our team gets to spend some time with the candidate, and can turn any application down without having to provide any reason for it. Through this process, Jim just came up with some interesting statistics about our team members, assuming that we would hire this candidate:

  • 100% are male
  • 100% natively speak a language other than English
  • 87.5% natively speak French
  • 87.5% are under the age of 49
  • 87.5% drink coffee
  • 75% have children
  • 50% are follicly challenged
  • 12.5% are left handers
  • 12.5% prefer sparkling water to tap water
  • 12.5% are based in the northern hemisphere
  • 12.5% have Spartan origins

Even though we’re an equal-opportunity employer, our demographics clearly do not represent that fact. I used to think this could be a problem. Today, I really do not care. Culture is what matters, and culture doesn’t give a damn about statistics.

Bay Area Health Insurance rocks

When we started Sutoiku, we worked with Bob Vinal at Bay Area Health Insurance to setup our health insurance plan. Along the way, Bob introduced us to another company that I won’t name which helped us setup our Flexible Spending Account (FSA) plan.

To make a long story short, this company didn’t do their homework very well and we ended up spending $450 for something we did not need. We asked them for a refund, but they refused. Bob felt really bad about it because he was the one who made the introduction, and today we received a $450 check in the mail. He really did not have to do that, but he did it anyway.

Jacques and I were really impressed about that, so we went back to Bob and told him that we had destroyed his check and offered him to pledge $100 to our Kickstarter instead. He might not need our software, but it would help us a little bit, and it would bring a ton of good karma into an already excellent business relationship.

Well, it did not take long for Bob to take us on our offer. But because Bob is a really great guy, he pledged $400 instead, which made Jacques and I totally speechless. Not really surprised, but positively ecstatic. So here we are, we crossed the $10,000 mark, in a super awesome way.

Bob, to you and your team at Bay Area Health Insurance: thank you!

And to all entrepreneurs in Silicon Valley: if you need a health insurance plan, give Bob a call!

Valve as role model

Be it for Flatland or T-shaped people, Valve Corporation is a major role model for us. And after this excellent New York Times article, I would expect that it will be for many more companies. But if you’re considering such a model for your company, keep in mind these recommendations:

  • Implement this model from the very first day.
  • Do not try to reengineer an existing company with it.
  • Be prepared for it to be a lot harder than it might seem.

Open kitchen culture

More and more people who come across our blog are amazed at the openness and transparency of our communication with the outside world, to the point of wondering whether competitors could take advantage of it against us. Indeed, when you read through our posts, which are slowly but surely becoming more frequent and more detailed, you can easily imagine how all this information could be turned into a competitive weapon.

To be honest, as we’re moving along, we keep asking ourselves the very same question, yet always come back with the same answer: the net benefits to us are still positive. In other words, the benefits of an open communication channel with customers, partners, investors, and employees far surpass the risks associated with the dissemination of proprietary information to our competitors. Here is why.

By being brutally honest about ourselves and sharing with anyone interested the good, the bad, and the ugly about our business, we’re creating a level of trust that no amount of marketing nor public relations will ever be able to match or even come close to. And trust has to be the most valuable asset of any business.

By the same token, any nugget of wisdom that competitors could glean from our posts won’t be very helpful to them if they don’t take the whole package. By that, I mean that our communication style is only one of the many aspects in which Stoic is different, from the way we make decisions (unanimously), to the way we manage product development (user-driven development process), to the way we develop software (refine). If anything, our serious competitors should never read our blog, for it might take them down the wrong path, as far as their own business is concerned.

And if a competitor decides to emulate everything we do to the letter, we’ll take this plagiarism as the best form of flattery, and we’ll reassure ourselves in remembering that, by definition, we’ll always be a blog post ahead of them.

Today, a friend of mine came up with a great analogy to describe this way of thinking, and the culture we’re trying to establish in our fledgling company: it’s very much like a restaurant with an open kitchen. Customers love it, because they can see how the food is made, whether it’s done in sanitary conditions, whether the ingredients are fresh, whether the cooks are clean and attentive to details, and whether they have things under control.

Of course, with an open kitchen, all your mistakes and shortcomings are exposed in the open for anyone to see. And if you become sloppy, if the kitchen is dirty, or if you start buying products of poor quality, customers aren’t likely to come back. But in that case, I would argue that you should close shop anyway. The restaurant business is a highly competitive one, and only the best survive. As far as I can tell, the open kitchen strategy is one of the best available techniques to extend your restaurant’s lifespan.

To a very large extent, we’d like to manage our software business as an open kitchen restaurant. This kind of approach was pioneered by a few open source software companies a decade ago, but it was applied to the software development process only. In our case, we’d like to push the enveloppe and apply it not only to software development, but also product development, as well as marketing, sales, human resources, corporate strategy, and many other aspects of our business.

Quite frankly, we have no idea whether it will work or not. It’s certainly too early to tell, and we’re bound to make plenty of mistakes along the way. But as long as we’re willing to face them and their consequences in an honest and open manner, I must believe that everything will be fine in the end, and that we will have a ton of fun while doing it.

What else could really matter?

When good enough is enough

In my previous post, I forgot to mention that quite a bit of code related to the Workflow datatype still lives in the Data CRUD API and the Record View. This is because the Workflow datatype is a bit special, in the sense that no more than one field of this datatype can be used within a given object, and we’re not expecting anyone to develop custom datatypes that would be as complex as this one. So, for the time being, we will keep the code as it is, because it’s good enough, and we’re in serious need of shipping our software to ourselves (for our internal needs). Down the road, once we find some free time, we will run this very last mile of refactoring.

No budget for QA

During Friday’s interview process (Cf. How we make decisions), we also spent a fair amount of time discussing about Quality Assurance (QA), and the reasons why we do not want to hire any QA engineer. Clearly, our upcoming Vice President of Engineering had some issues with our approach, and we will need to find a way to make him comfortable with it, or we will have to revisit our position. One way or another, we must find a model that we can all support. That decision will require unanimous support.

In a nutshell, we believe that QA should be handled by the people who write the code in the first place. What this means is that software engineers should be responsible for writing the functional and unit tests they need to validate and maintain the code they’re writing. And whenever we do peer programming (which we end up doing more and more), peers should spend a fair amount of time going through their peer’s code, pushing the envelope of existing tests as much as possible, as well as writing new tests.

Using GitHub, developers work on their own clone of the entire codebase for as long as they need. Once they’re ready, they can push their commits to the Dev branch. From there, additional testing and peer review are done, the latter being handled by senior developers (our CTO being first among them). If the code and test coverage is deemed acceptable, commits are propagated to a Stage branch, which is used by all employees internally for running our business and by our closest partners and most trusted customers. After a while, commits are propagated to a Prod branch, which is used by everybody else. To summarize, the tree looks like that:

Local ➔ Dev ➔ Stage ➔ Prod

This simple process ensures that we have plenty of opportunities to catch bugs and fix them before they affect too many people in disruptive ways. It also instills a sense of ownership and responsibility in the mind of developers, which helps them produce better code and tests right from the get go, before bugs have any chance of creeping up. And it guarantees that we don’t waste a single dime in trying to improve communication between developers and QA engineers, for they’re one and the same.

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.

What software companies need

We got a step closer to the epiphany this morning, following a meeting with an old friend of mine who started his own software company two years ago. He built a really cool decision management application that can be deployed either in the cloud or on premises. Here is what we learned from him:

  • Supporting ad-hoc workflows for case management is the holy grail
  • Picking the perfect NoSQL database is close to impossible
  • Supporting a hybrid deployment model is really difficult
  • Developing mobile user interfaces is very expensive
  • Hiring good engineers is really hard

All these are things that Sutoiku can help with, to a certain extent.

Supporting ad-hoc workflows for case management
This is one of the main goals we have for our workflow engine. While we’re making workflow automation ten times easier than with any other tool we know, we need to gain another order of magnitude in terms of simplification if we want to support ad-hoc workflows that are used for case management. We still have quite a bit of work ahead of us there, but one of our customers is sponsoring this effort, so we should have a really good solution before the end of the year (Cf. A new approach to workflow)

Picking the perfect NoSQL database
Such a thing does not exist, by definition. The whole point of NoSQL is to offer a wide range of options to pick from in order to get the best possible datastore for a particular usage pattern. If your application needs to support a wide range of patterns and these patterns are bound to evolve over time (which they are, most likely), the right NoSQL database will change as well. This is why our Object Data Mapper is being designed to support both SQL and NoSQL datastores. Build once, deploy anywhere…

Supporting a hybrid deployment model
Our unconventional three tier architecture  supports a hybrid deployment model, whereby what we call our server can be deployed either in the cloud or on premises, and the cloud option supports virtually any cloud. We still have quite a bit of work to do there, but the main architecture pieces are starting to fall into place.

Developing mobile interfaces
We don’t have a good story for mobile yet. But we’re working on it…

Hiring good engineers
If you work for a software company and you decide to build your product on top of our platform, you can outsource some developments to us. In some cases, we share the Intellectual Property (IP), as we did for the query builder. In other cases, the IP remains yours entirely. And we’re in the process of setting up our first offshore development team in China, so we can help you reduce development cost in a significant manner.

Now that we’re starting to extract some patterns, we need to validate them with more prospects, and turn opportunities into deals. Obviously, this is easier said than done, but this is one of the things that Jacques-Alexandre is really good at, so I’m not too worried…

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.

A step closer to the epiphany

One former business partner I worked with for far too long kept telling me about the four steps to the epiphany. I never followed his advice, but I now realize that I made a mistake, and I won’t make the same mistake twice.

For us to be successful, we must listen to the market carefully.

Sutoiku is a platform for building cloud applications. It’s as easy to use as a spreadsheet, yet as powerful as the core technologies it is built upon (Node.js, Big Data). As such, it can be used by three types of organizations:

  • Small businesses or large enterprises
  • Systems integration firms
  • Independent software vendors

We believe that we have a fairly decent understanding of what the first two need, and why they will love what we’re building. But the third one are more of a mystery to us, therefore we need to talk to as many of them as possible.

More specifically, we’re targeting small to midsize software vendors developing applications that are sold to business users and delivered over the cloud. We’re especially interested in companies that would like to use platforms such as Force.com or QuickBase, but cannot for a variety of reasons (pricing model, deployment model, scalability, etc.).

If you’re working for such a company and recognize your firm in this profile, please give us a buzz. We’re not trying to sell anything at this point. All we care about is to learn more about the challenges that you’re facing, so that we could develop a better understanding of what the market really needs.

This will take us a step closer to the epiphany.

Corporate culture vs. local culture

Everything in my past professional experience tells me that a company’s culture is set at a very early stage, and virtually impossible to change over time. A company’s culture could be viewed as its DNA, and DNA mutations usually create pretty scary outcomes…

In such a context, the discussions we’re having internally about our corporate philosophy are all the more important and urgent. While we don’t want to become religious about it, the flat organization advocated by companies like Valve (make sure to check their employee handbook) is especially attractive to us. But it’s also full of challenges, and one should be very thoughtful when considering it for its own startup.

Just to refresh your memory, the kind of flat organization we have in mind dictates that there are no managers, that employees are not hired for any particular position, and that anyone is free to do whatever he or she wants, or rather whatever he or she thinks is in the best interest of the company. Clearly, this is not a model that can work for everyone, and it brings many more questions than I care to answer on this blog.

For example, one question we’re asking ourselves is whether or not such a corporate culture could be exported to foreign countries where we will have operations. This is where a corporate culture must mesh with a local culture, and when some incompatibilities might arise.

This issue is all the more relevant that we’re about to setup our first offshore development center in Shanghai. Traditionally, corporate cultures in China are very hierarchical, and the main goal of a freshly-graduated engineer is usually to become a manager as soon as possible. On the face of it, this is not a very good match for what we would be looking for, and one might suggest that we should either reconsider our desire to implement such a flat organization, or reconsider doing it in places like China.

While this would certainly be a sound advice from a risk management standpoint, this is one we would listen to first, then flat out ignore. Not that we think we know better (well, maybe we do, but that’s beside the point), but because we believe in the concept of self-fulling prophecy.

Let me explain.

By adopting such a counter-cultural corporate culture and optimizing our hiring and training process for its particular requirements, we automatically differentiate ourselves in a highly competitive job market and increase our ability to attract the best talent. It clearly reduces our ability to scale, by elongating the time it takes to hire and train new employees and by increasing the risk of failure. Nevertheless, by doing it in a very large pool of talent (Shanghai has a population of over 13 million), we make sure that the law or large numbers is on our side. And we don’t have to hire thousands of engineers overnight. In fact, a dozen of really good ones will be all we need for the next twelve months or so.

Our new VP of Engineering (a Chinese citizen) is only starting next month, and we have yet to discuss any of this with him, so I wonder what he will make of our current brainstorming. But whatever is reaction happens to be, I know that the challenge of developing such a corporate culture in places like China has to be one of the most interesting ones we will have to overcome.

Man, this is a ton of fun…

If all you have is a hammer

If all you have is a hammer, everything looks like a nail. More often than I would wish for, I fell victim to this law of the instrument. When I built my first Business Process Management System, everything looked like a process. And when I built my first object-oriented application development platform, everything looked like an object. Unfortunately, not everything can be cleanly mapped to a process or an object, especially when such mapping is constrained by a product’s own limitations.

In building Sutoiku, we try to keep this lesson in mind, and apply core concepts and patterns only when they make sense. We also try to avoid any religious position regarding these concepts and patterns. Whenever and wherever they make sense, we embrace them fully. But when and where they fall short, we try to look beyond for better solutions.

Sometimes, the better solution is neither process nor object, but a fusion of the two, where simple processes (I should call them workflows to be honest) are seamlessly blended into objects. This is how we approached the overall issue of workflow orchestration, and it’s starting to really pay off.

Some other times, neither pattern makes sense, and we need something else. This morning brought a good example for such a situation. As we’re embedding our new query builder into our platform, we had to develop a new CRUD API to manage the lifecycle of queries. We came up with an API made of two classes, with the following methods:

QueryManager

  • create (new query)
  • get (existing query)
  • getList (of all existing queries)
  • import (query)
  • search (across all existing queries)

Query

  • run
  • update
  • delete
  • clone
  • export
  • share

Once the API was defined at a high level, we started giving thoughts to the way we would implement it. Our initial reaction was to store queries within the objects they most directly relate to (within the Opportunity object for EMEA Opportunities for example). But after further reflection, we realized that it would be far from ideal.

The reason for it is that queries are semi-structured pieces of content, while objects (at least the ones we manipulate) are optimized for dealing with structured content (the kind of content you store in a relational database). In essence, we were trying to force a round peg into a square hole. Also, in doing so, we would make it a lot harder for us to properly manage the lifecycle of queries, especially when it came to import, export, and sharing.

It then hit us that we needed another concept or pattern for semi-structured content, that is, content that could be managed through documents instead of objects projected to database tables. While this is obvious to anyone developing applications with some NoSQL back-end, within the context of our particular architecture, it has significant implications that we’re still trying to grapple with.

After we discussed the pros and cons of the approach, we proceded to develop a first prototype, and early results are very encouraging. In a nutshell, when a user creates a new query, a new document storing the JSON definition for the query is automatically created and added into the user’s cloud drive. From there, the query can be shared with others, exported from one account, and re-imported into another.

What’s interesting with this approach is that the document (think file) actually storing the query’s definition can contain additional information, such as which object the query relates to, past results for the query’s execution, and many other useful things that would not really fit into a relational database. Also, because the document storing the query can contain arbitrary content (think rich text), we can add to the query itself all the documentation needed to run it or customize it, either from the query builder (very highly recommended), or directly from the JSON serialization (not for the faint of heart).

If all you have is a hammer, go buy a screwdriver and some pliers!

Corporate philosophy

As our company is growing, we’re being tempted to introduce more and more rules and processes to keep up with things. This is one way of doing it. Another is to come up with a simple philosophy that has the elements of success built into it, and while we do not know what it is just yet, we’re getting a ton of ideas from the way Valve is doing it (Credit: CTO).