Why we decided to do away with meetings and remove bosses from our start-up

I would like to go into details about these two items along this article.

Meetings are no longer viable in our start-up

In order to give some context, we are two IT engineers. We founded the project in 2008 and we had worked in big corporations such as HP, IBM, Intel, and Microsoft.

Back then, if we both had to say which were the most annoying things which impinged on our productivity (software development), we would always come to the conclusion that we hated meetings.

Based on this reality, we decided to carry out some research. We realised that there were several factors that supported our stance, even Paul Graham, the consolidated entrepreneur in North America says: "For a programmer, the cost of attending a meeting is always higher."

We would definitely not implement a start-up from scratch (with all the effort and dedication this takes) to deal with aspects that we didn't fully support. Furthermore, we were convinced that when appointing new programmers to our project, they would support our outlook too: No More Meetings.

I personally consider that the problem for a developer lies in the fact that in order to achieve maximum productivity, they necessarily need, on average, four consecutive hours of work to write code. Any meeting that interrupts this process leads to wasting not one or half hour, but half working day, minimum. Either the first half of the working day (from 9am to 1pm) or the second one (from 2pm to 6pm) is wasted.

I admit this item may seem rather radical at first. However, it is 100% accurate.

We don't consider bosses to be essential

The second item we defined from the first moment, based on our past experience, was to remove managers from our start-up. But why?

There are several reasons; one of them is that we always saw a profound disconnection between our job as developers and our bosses. We wondered how somebody could tell us what to do, and furthermore and even more important, supervise us, if that person didn't have the technical knowledge that we did have.

Even the communication language was different. While a programmer talked about SQL sentences, JavaScript, Ruby on Rails, PHP, etc, bosses only wanted to know the status of the project and how much they had ahead to finish it. But they didn't pay attention to the most important things: How to solve the problems, and discussing the search process to find the best solution to solve the problem.

That is to say, if a task was assigned to you, it wasn't important how you solved any problem that could arise, as long as you finished the task (as soon as possible.) So, if you completed what was requested, no matter how, then you were a good employee. This is not reasonable because it leads to programming in any way, usually wrong, without the correct structure - which doesn't make it scalable in the long term. And this is, eventually, the origin of real headaches.

We also carried out some research about the market in relation to this item and we found that, none other than Larry Page, co-founder of Google, considered that "engineers must never be supervised by bosses with [who] lack of technical knowledge."

How do we make this come about?

After explaining the reason why we took the previous decisions (the foundations) and after several years of experience, we came to the conclusion that you CAN in fact work in a technological start-up with this new methodology.

Each start-up can find their path and even improve it much more than we did. However, we'll share what we've learned until today.

In the first place, as we don't have meetings, our only means of communication (pillar) is a very simple program that we developed and we named it "iAutonomous."

It's a system that works as SaaS, where there's a list of tasks to be performed in which each of us can create a new task or join an internal project to start working on. Each one of these activities is and must always be aligned with our short, mid and long-term goals.

Within the system and once we have created a project or joined one, we can see its progress, we can see on which projects our teams are working on (under development) and what things still need to be done (pending.) In this way, it's not necessary to waste time every day on face-to-face or telephone meetings since each one knows specifically on which stage they are at all times.

Furthermore, our mail had transformed into a To-Do list which organised our day and by using "iAutonomous" we eliminated almost entirely the waste of time the email-list meant since it wasn't effective from any point of view.

Another aspect is that by not having meetings or bosses, all of our communications, almost 90% of it, is written. We use our tool "iAutonomous" and sporadically Google Hangouts for our internal written communication.

This has as a consequence a very important factor: All of our interactions are asynchronous. This means that we can answer queries, suggestions, activities, etc when we have the time for it.

This solves our main concern: to be able to be productive. If an engineer in our start-up wants to develop a new functionality for our software and he decides to work five consecutive hours until he finishes it, he can do so without any problem. And it can be achieved due to the fact that nobody will call him or arrange a meeting with him and nobody will interrupt him.

When our engineers have the time, they respond to any interaction in an asynchronous way once they have finished doing their job.

I hope this article sows the seed to be able to change, but most importantly, to improve current work mechanisms. Any query or suggestion is always welcome.