Teamwork methods in a startup

Any team wishing to adjust the working process sooner or later faces the need to establish certain rules and agreements. As practice shows, at the initial stages the team’s work is based on conditional agreements that everyone undertakes to fulfill. And even if all the participants are responsible and timely cope with their duties, the process of working with time still begins to suffer. Why do such problems arise, and how does our team deal with them? We offer to know this by looking on the other side of a startup.

Stage 1. Preparatory.

At the first stage (2 years ago) we didn’t think at all that our work should be structured in any particular way. At that time, dreams and high expectations outweighed the real state of affairs, so we acted strictly intuitively - everyone should do their part of the work as quickly as possible, and everything else is formed by itself. We did not think about the consequences of these or other actions, did not try to foresee possible mistakes, and each time, having filled the next lump, we plunged into a state of frustration. It seemed to us that we were completely incapable of interacting with each other.
')

Stage 2. Introductory.

Time passed, and the workflow became less chaotic, although productivity still left much to be desired: deadlines were broken, negligible amounts of work were performed, and, worst of all, the understanding of this did not come immediately. The problem was that we had no opportunity to objectively evaluate our productivity, because we all relied on our memories and sensations.

The time has come to change something, and we began to think about the methods of teamwork. First of all, it was decided to write down somewhere and distribute tasks and subtasks among themselves. For these purposes, we began to use the Russian task scheduler teamer .



It turned out to be quite convenient, however, it is not clear why our activity there very quickly died out, and we returned to the former way of life (all work took place in Skype’s chat, alternating with rare meetings). Such a simple and, in general, inefficient methodology after some time still led us to launch the project.

Stage 3. Breaking Point

The launch brought with it a large number of problems, and it became necessary:

- process and respond to feedback in time;
- keep a record of sensible suggestions for improving the service;
- monitor and correct bugs found in the service;
- synchronize actions within the team;
- set real deadlines for a particular task;
- assess the amount of work for their competent execution;

Then the chat in Skype stopped bringing practical benefits, and we began to call up very often. So we lived the first six months after the launch of the project. After a while, being on the verge of creating a second version of our service , we decided that the workflow requires much more changes. Our new partner, who is also an investor, also pushed us towards this.

Teambox

It was Teambox that became the service, where to this day the main working processes of the team are organized. In Teambox, we use only 2 tools: Tasks and Discussions.



Our structure tool "Tasks"

- design;
- layout;
- programming;
- functionality that will help improve the service;
- daily reports on the work done;

In each of the sections a list of necessary tasks is published, for each of which, if possible, a time limit, a priority are set, and additional discussion is conducted. Thus, we do not waste time on unnecessary conversations, but always know what needs to be done next.

Our structure of the discussion tool

- ideas (any ideas are discussed, the most valuable of which are transferred to the task list);
- design (any moments / wishes on design are discussed, screenshots / examples from other services are published);
- presentations (they will be discussed later);
- team meetings (collectively discusses the time and day of common calls);

Github

At the moment, GitHub not only performs the function of a repository for storing code, but is also used as a bug tracker. It takes a few seconds to create a “ticket” and assign a responsible person.

Skype Conferences

Even at the initial stages of work with the investor, we agreed that we must call up once a week and an unspecified number of times for emergency cases or urgent matters.

The weekly phoned is a report by one of the team members on the part of the work he is doing. Usually the report is divided into two parts:

1. What has been done over the past period;
2. What the team member is going to work on in the near future;



After speaking on each of the parts, the investor and other team members ask their questions, if any. Thus, we always have relevant information about the process of working on a project.

Since there are only three of us in the team (designer, layout designer, programmer), we make the fourth phoned one by one where we arrange a small psychological session, namely, we throw out all our feelings and emotions regarding the work on the project, discuss current problems and issues . This helps us to "let off steam" and move on in the usual way.

Priority of implemented functionality

Over time, we have accumulated quite a lot of various features that, in our opinion, can improve service. But we try to adhere to the rule: “The simpler, the better”, therefore, all ideas concerning new functions are subject to strict selection.

Each idea is evaluated by 4 criteria / goals of the project (marks from 1 to 10 are set):

- Does this feature help to attract users ?;
- how much will it satisfy user needs ?;
- how much it will help keep the user on the site ?;
- the complexity of the implementation of this functionality;

Conclusion

This is exactly the situation in our team today, although we are aware that we have something to work on in terms of improving interaction. Summing up, we can say that the interaction processes in a team should change naturally. Changes are needed when the whole team needs them. In another case, the use of various methods of work will not be fully realized, which may not only not improve, but also worsen the result of your activity.

We hope that this material was useful for you. Any suggestions as well as sharing your own experiences are welcome.