Why We Decided to Do Away with Meetings and Remove Bosses from Our Startup

 

 

In order to give some context, we are two IT engineers. We founded our 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 what were the most annoying things that impinged on our productivity (software development), we would always agree on which one came first: we hated meetings.

 

Based on this reality, we decided to carry out some research. We realized 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 accepting new programmers to our project, they would support our outlook too: no more meetings.

 

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

 

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

 

 

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 disconnect between our job as developers and our boss’. 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 thing: how to solve the problems and discuss the searching process of the best alternative 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 programing 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 lack of technical knowledge.”

 

 

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 pairs are working (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 organized our day and by using “iAutonomous” we eliminated almost entirely the waste of time the email-list meant since it wasn’t effective under any point of view.

 

Another aspect is that by not having meetings or bosses, all of our communication, 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 so he decides to work 5 consecutive hours until he finishes it, he can do it without any problem. And it can be achieved due to the fact that nobody will call them or arrange a meeting with them and nobody will interrupt them.

 

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

 

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