Be bold

Thanks to the networks of our founders, we could occasionally find chances to talk to the founders of successful startups in the area. In one of these talks; the founder of a now-successful firm have said to us that we should be bold.

We should make bold decisions, we should not be afraid to try new things that our competitors did not even think of trying. Many people from the team suggested different ideas (which some of them I still think are very bold), but we have never even bothered to execute many of those ideas. Instead; we became a mobile-focused startup. At that time, most of our competitors did not have a good experience at mobile. So we built one.

Well, I thought our mobile apps were very good at that time. But I suppose that’s not bold. That’s not enough to conquer a market. It might not be the situation here in Istanbul, but I suppose SoLoMo is some kind of joke around Silicon Valley. Who is not trying to define their startup based on “social, local, mobile” terms any more? Why didn’t we try those other ideas which came mostly from very talented engineers? Why did we end up with what is mostly a local copy-cat of some successful startup in USA?

I don’t know if they would end up successful if they have tried to execute some of those ideas, but I think we were not bold enough.

Be transparent about all the metrics you have

I always mentioned the importance of this. There are successful startups who even share the paycheck of their founders. Giving access rights on Google Analytics is not enough. We should have spent enough time to design a panel to share key metrics with everyone in the company. How much money we’ve got left, our growth rate, app downloads, number of paying customers should have been easily observable by everyone in the company. We should took the time to implement such panel (and it would not take that much of time).

We were not good at measuring and making measurements available to at least everyone in the company.

Don’t work hard, work intelligent

Our engineers spent many nights at the office. Well, work is endless, and I think sprints are useless.
Our development cycle consisted of these things: We had lots of feature implementations and bug fixes at backlog. Every Monday, we would define which of these tasks we would be dealing with that week, we would make an estimation about how much time it would take for each task and we would prepare the sprint of that week by assigning tasks to people with a consideration of priority and time.

I think there were problems with that development cycle. The first problem is that most of the time, we were learning a new framework (we have used a lot) and were not able to make a correct estimation about how much time we would need for a task. This created never-ending sprints and “Why we were not able to finish the sprint this week?” themed talks, which also created unnecessary tension at the workplace and we should probably have not done it ever.

The second problem is about expectancies. When you have a list of 10 things to be done that week and you finish 6 of them in Monday, you tend to think that you have done a lot that day and would be able to work in peace for the other four days. But then your manager sees that you have so much time and not so much work, and adds a couple of more tasks from backlog to your sprint on Tuesday. Well, I am not someone who comes to work and expects to spend a lazy day, but what is the point of making a sprint if it will change on the way?

The third problem is that, most of our tech staff could not find a break. We always had sprints which required a lot of work. Well, we should have prepared lighter sprints at least once a month and be mentally stronger instead of working like a machine. Most of the time our development team was overwhelmed.

I think that making a list of feature implementations and bug fixes is good and we should also may or may not have continued to make an estimation about how much time a task would require. We should not have set expectancies at developers’ and managers’ minds by pointing out the things to be done that week. We should have simply put them in order by their priority, assign them to people, do them and move forward. The problem of being overwhelmed would have vanished in such a development cycle with a strong communication, too.

But these are just my thoughts. We could have found better ways by talking about these issues more often and openly. Although our team consisted of very clever people, we were not very good at working intelligently instead of working hard.

Make your team comfortable with economic issues

This is one of the most important aspects of running a startup. If you already have a funding, please be generous.

Be generous to your workers. They should be economically comfortable to be able to focus on their job in the company. Even paying for their meals would improve the morale.

Keeping salaries above the industry standards would attract talent. I would also make everyone’s mind clear about the stock options from Day 1.

I will not give details about how we handled economic issues at metrekare.com

Ask your team members’ opinions about a potential hire

Company culture is a living thing and it evolves with every new hire. Especially in small teams, a new co-worker is not a small change.

I would consider asking every team member to talk to a potential co-worker before hiring him/her. I might end up not hiring that person if the current team thinks he/she is not a good fit.

I will not give details about how we handled hiring processes at metrekare.com

Always stand next to your team

If I were running a startup, I would emphasize the importance of having a good team, and I would not take all the credit myself. I remember when I saw the image of keen.io team in an article about their startup, and I thought “This is how a startup team should show up in tech blogs.”

Here is that picture.

I think we’ve made both rights and wrongs about that.