The foundations of azing were laid in Indonesia in 1990, when I tought myself programming on my parents' Bible translation PC...
Jungle to Civilization: Why we need azing
My name is Daniel Mettler, but on the internet you will usually find me as an iJungleboy. My pseudonym originates from being a missionary kid in the jungles of Papua New Guinea and Indonesia.
During these 11 years in the jungle, I had plenty of time and a Bible translation PC to learn to program. I spent countless hours learning to create computer games.
In 1994, at the age of 17, I came to Switzerland to get a "reasonable" education - so first to learn German and French, and then hopefully a "real" Swiss job :).
But as fate would have it, things turned out differently. The internet had just been opened up and as a "geek" I earned some extra allowance by creating websites. Since my missionary family previously lived off of donations, an income of a few hundred francs felt like a fortune.
Then I decided, that instead of studying at the ETH in Zurich, I would become an entrepreneur. So on the first of January in 1999, a friend and I started the company 2sic to develop websites, online databases and the likes. As the company grew, we faced a huge challenge: survival.
Survival by Standardizing...
The greatest challenge of our times is the standardization of...
...actually kind of everything?
At a typical small company, there are thousands of little things that are spontaneously implemented at the discretion of the employee. In established occupations with a "proper" training, aspiring professionals learn what works and what does not. But in a job that is reinvented every two years (like web development) and in activities that you try for the first time (like your first conference booth), this best-practice standardization is missing. And it's also missing in processes with many people whose work has to be coordinated.
My self-trained education from the jungle turned out to be a blessing in the web industry. Since everything moves so quickly, keeping up only works in self-education mode.
Anyone waiting for a course lags behind the current features by at least 2 years. But now the standardization problem begins: If every employee learns something himself and implements something at his own discretion, some work will be good and other work will be terrible. Later on, even the good work will cause problems, as they are not planned to fit follow-up work.
In our company we didn't just have quality issues. We ended up with a lot of unbillable clean-up work everywhere, just to keep things going. This "hidden cost" is the reason why most web companies fail and dissapear after a few years.
Standardization - But Keep the Team Responsible
Like any company, we first started with simple standardization and internal trainings to streamline how we work. But it was far from enough: new employees had not yet had this training, and new findings had to be constantly collected and distributed. This was literally just a drop in the bucket. And our bucket was sinking.
After the first 6 years our company had grown to 6 employees, and I spent all day traveling between desks to coach and answer questions. It was a nightmare.
Things were even worse when we had to work on old projects. I was usually the only one who still knew how it had been built - or botched. Working like this was simply not fun anymore.
All I wanted, is that employees do a great job, and think for themselves. Was this really too much to ask for? Yet I kept my steadfast believ, that my staff wanted this as well, but that it was almost impossible due to the complexity of our work.
And then it dawned on me: I needed a system that orchestrates the work and knowledge. But with processes and instructions written by the employees themselves, so that they could be fully responsible. Part of this inspiration came from Wikipedia, which was just becoming famous at the time.
Since I was certainly not the only one with this problem, I first sought after existing solutions - but nothing could solve the real problems. Why this is the case, I explained in the blog Why team operating systems fail. So I decided to develop a new "team operating system".
First Attempts 2005 - 2017
We got started and had a reasonable solution end of 2005. It was a mashup of Outlook, SharePoint, Infopath and some macros. It worked, and saved our company, but was more of a pretotype than even a prototype.
When I showed the solution to other entrepreneurs, it became clear that everybody wanted something like this. But of course, our pretotype wasn't scalable.
So, we decided to recreate the solution for the public and spent 3 years to create a web based prototype which we called SwissChecklist. It was much better, but still not ideal for the general public.
In the meantime, web technologies got better, forcing us to stop development on V2 and start on a V3 which used modern web frameworks. By the end of 2017 we finally had an internal prototype which was purely web-based.
Time to create a real solution and share it with the world. We call it azing.
azing - the Reboot in 2019
This year 2sic has it's 20th anniversary. We're really excited to finally release our core vision which has been keeping a secret for so long.
This year we'll release azing in steps, as each part matures. New features will first be made available to select pilot users, and as the features stabilize they will be published for the whole world.
The Free Checklist Wikipedia
Our vision is a gigantic, free encyclopedia of checklists. This will help both people in the developed world as well as the third world, who previously didn't have access to this kind of knowledge. This is the spirit of open source: Share knowledge, for free.
I'm super psyched to be part of this - join us!
Best wishes from eastern Switzerland and Liechtenstein,
Daniel, the iJungleboy