Since we announced the Modern HTML Email Tutorial on the 23rd of November last year, we published only tech-heavy articles every second week. This time it's going to be different.
This and the next article in this series are about how to manage people, how to motivate, and how to delegate in an efficient way that things will be predictable.
In the last five years, we have grown from an idea to a stable company of 15 people. There were times when only full-time employees worked at our company, and there were times when only I remained on the project full-time. At the moment, there are 5 full-time and 10 part-time people at the company.
These extremely different conditions mean that we had to change our management style and methods from time to time. We had to adapt to these circumstances to survive as a company.
You always have to seek out for new methods to manage the chaos around you. This is especially true when we are talking about the management of part-time employees. There is an extra management cost, but if you build your company with this in mind, then you can have a lot of very motivated people working together with you to build a great company.
In this article, I'm focusing on managing a small team consisting of full-time employees. In my next article, I'm focusing on managing part-time teams.
Since this story is about growing a company from 0 to 15 people, I mainly recommend it to SaaS startups who have not grown to this level yet. Secondly, I recommend it to people who are interested in employing more part-time people, but they find it difficult to manage them.
The Early Days
Like many other startups, we also started off in a garage. Not exactly a garage, because we worked at my apartment, but the principle is the same. We worked irregularly because all of us had other jobs. I was teaching programming at a university, which turned out later to be a very good source for talent. Since there were only a few of us, we did not really need any kind of project management. It worked perfectly, communication on this level (3 people) was very easy.
Every project at the beginning is not very well organized, but to be honest, it does not really matter. You don't really need strict management policies when you have one or two developers working on a project.
After we got our investment, we hired two full-time employees (one of them from the university I was teaching at). Maybe it does not seem to be a big difference, but managing a five-people company is totally different from managing a three-people company. There were three main things:
- Losing focus: It often happened to us that we tried to solve everything at once and eventually very few of those things became reality.
- Lack of information/miscommunication: If there are more and more people then it will be more and more often that for a subset of those people certain issues are crystal clear but not for others. It leads to situations when people think that the others are stupid. It's definitely something to avoid.
- Planning ahead was very hard: As mentioned before, we often lost focus, but also, we did not really plan the details of features thoroughly, so it was really hard to estimate when certain milestones would be ready.
On top of these very serious issues, there were a lot of distractions in the office. It was very chaotic and I think the productivity was not even close to the level where it could have been.
We needed a formalized system, which solves those problems.
SCRUM for the Win
Our solution for the problems above was the SCRUM methodology, which is a set of practices bound together in a way that works very well for software development teams. I think you should not stick to a specific pre-defined set of rules strictly, but you have to pick those which work best for you.
There are many great articles about the SCRUM methodology, so I don't want to spend the time to describe the different parts. If you are not familiar with these concepts, I suggest you search for a good article about the SCRUM methodology. In this article, I will focus on what worked well and not so well for us.
It took us some time, but eventually, we could pick those parts from the SCRUM methodology which worked great for us. Actually, we were very strict with most of the things and everything just clicked.
I have to emphasize one thing here. We were a team of 5 full-time people. When you think about part-time employees, you have to radically change your mindset, but I will talk about that in the next article of this series.
Sprints
We tried one- and two-week long sprints. Both of them worked well for us, but in different situations. Shorter sprints are great if you want your team to focus for a short period of time, but you still want to add or remove things relatively quickly. I think you should not think about releasing new things faster than this. Longer sprints are better when we needed to develop a little bit bigger features. We tried even three-week long sprints, but that was just way too long.
We had our sprint reviews and sprint plannings on Wednesdays. The reason is simple. If it's in the middle of the week, then usually you can finish it faster, because people are in the flow. We have tried Mondays as well, but then everybody was scratching their heads to recall what happened and what should be done differently. Also, it took some time for people on Mondays to recall the details of some features that were very well planned already. It just took too much time. (You know, weekends sometimes erase your memory from the last week...)
Sprint reviews were great. We created retrospectives, action items for improvement and there were people responsible for those action-items. Although it was great for the team, I often felt that it takes too much time and sometimes we did not use it properly.
Sprint plannings were very useful. We estimated the business value and the story points of every user story and based on those we chose which ones to implement in that sprint. After that, we associated well-detailed tasks to the user stories.
To be honest, estimating the story points never worked really well. Sometimes it seemed like we are doing it well, but after a few sprints, we failed again to estimate well. I think it can have a few reasons:
- Planning and estimating like this is just bad. I think it's much better to plan the tasks ahead of time and iterate over them for a while. In my experience, estimations will be much, much more precise that way. (After a while we started to create tasks during daily planning, not during the sprint planning. It also helped to keep sprint plannings less boring.)
- Involved people did not risk enough. I think there was not enough motivation to estimate well and to finish the tasks. We never had a rule to stay there for weekends if something is not finished, although that way everybody would have taken it much more seriously.
- Many people might not agree with me, but classical SCRUM is rather for developed companies, not for startups. Even if you think about the concept of user stories, that works well when there's someone who ordered a software from you. If you create your own product it's a little bit ridiculous in "As a user... I want to..." sentences. The other very important thing is that there should be the well-defined different roles, for example, the SCRUM master and the product owner. These distinctions rarely happen at startups.
Daily Activities
We had daily standups every day. This is a great way to see if the team has any problems and it's also a nice and controlled way to deal with those problems. I think daily standups are great if the team is interested in almost every piece of info or they can help each other. If it's not like that, then the standup is a waste of time for many people.
There was a very useful thing which we did at the beginning of every daily standup. We updated our totally manual burndown chart, which we draw on a piece of paper. It helped the team to realize if we were behind schedule. I know that there are many tools for this, but this ceremony had a really good effect on the whole team.
Besides daily standups, we had another very, very important daily activity, which is usually not practiced by most companies. It's daily planning. It can help the whole team to have a commonly shared knowledge and point of view of the upcoming sprints' features.
We did it every day half an hour before our usual lunchtime. This way we were sure that these meetings wouldn't take too long. Just get to the point, and if you don't have enough time to discuss something, you can still do that tomorrow during the next daily planning. If that issue was not that important, then you will discuss something else.
Daily planning helped us a lot. When it comes to estimations, it leads the team from total chaos to a relatively well-coordinated state where we could make very good estimations and things were finished when they were supposed to be finished.
A Few Words about Project Management Tools
Let me share a few thoughts about the project management tools we used. At the beginning, we used trello for project management. It's good for kanban, but not enough for sprints and SCRUM.
We turned to Jira but to be honest, we never liked it. Although you can accomplish everything with Jira, it's extremely burdensome to use and it just does not feel right.
Eventually, we started to use ZenHub which is simply the best project management tool so far. It builds upon GitHub's ticketing system and enhances its functionality with neat things, for example, Kanban boards and burndown charts. There are a few caveats but I can bravely suggest you and your team give it a try.
The Pomodoro Technique
As I mentioned previously, there was a lot of distraction in our office, even though there were only 5 people at the same time. Even if you introduce some kind of policy to keep everyone quiet, people tend to break those rules.
Here comes the Pomodoro technique into the scene. It divides your distraction-free time intervals in which you have to focus on a specific topic from the breaks, in which people can distract you.
Originally this technique was invented for individuals to work effectively, but we introduced it on company level. This way we synchronized the focus time of every individual in the company.
If you want to try out a Pomodoro tool with which you can synchronize your whole team, try marinaratimer. Although it's not perfect, we used it on a daily basis.
Synchronizing the whole company worked great for us because everybody knew when they can talk to others without interrupting them. Even if somebody stuck with some task, the longest amount of time while they won't get their answers is 25 minutes at max. (And they can always work on something else in the meanwhile.)
Summary
By reading this article you have gained some insights how the management of full-time employees evolved in our first few years. From total chaos, we changed to a strict SCRUM company and we also used the Pomodoro technique to keep our distraction-free times.
I want to emphasize again that one of the most important habits we developed was the daily planning. With the help of that, we could estimate much, much better and the scrum meetings were more useful for everyone.
It worked very, very well with full-time employees, but after a while, we started to work together with many part-time employees. If you are interested why SCRUM was not suitable for them and how we changed the management in our company to work effectively, then come back and read the next article in this series.
