The unspoken traps of working at a startup (part 1)
As a fresh graduate few years ago, I was really into the idea of working as a software developer for a startup to exponentially grow my capability and professional experience. Now after having involved with several startups, I believe I did make a right choice.
Having said that, along my bumpy journey, I have realized that there are several traps of working at a startup that you might fall into, which might halt your development of skills and worse, your career. In this series of articles, I will present those traps, which mostly from my own observation and experience.
Trap 1: Measure your contribution as the number of tasks that you have completed.
Many software teams today adopts the Kanban board as a way to track the development tasks (a.k.a tickets). Basically, the board has at least three columns, for example: “To do”, “Doing”, “Done”, where you put tickets with corresponding status in those columns. A normal work flow is the engineer moves a task from “To do” to “Doing” and finally to “Done” once the ticket is completed. No rocket science.
It is a great method as any member of the team can have a look at the board and grab a quick overview which tasks are still missing or done. But that’s a problem too, virtually if you might judge if a person is productive or contributing much values to a company, you look at the number of tickets completed at his section.
Consequently, as a member you will motivate yourself to complete more tickets, instead of trying to establish valued tickets. Then you will tend to choose those low hanging fruits first. Either it is a easy uncritical bug or just a small UI fix, you will go for it first and run out of time for the more critical tasks which will bring more values.
Even more dangerous, this approach of ‘quantity over value’ can bring an illusion to the engineer that he is productive and contributing values.
Trap 1 unlocked: Measure your productivity by the values that your completed tickets bring.
It’s easier said that done. You might argue. How can you judge your own ticket’s value? If you could already do that, then you would not have stumbled into the trap.
I would refer to a method pointed out in my favourite ‘back-to-the-basic’ book Rework by Jason Fried. Whenever you are about to start a task, you should try to answer these questions:
- Why are you doing this?
- What is the problem are you solving?
- Is this actually useful?
- Will the people use it?
- What could you be doing instead?
After going through these questions, if you are still comfortable to work on the task, then it’s truly worthy.
My other method is always start the day with the most important and challenging ticket. Later in the day, when your cognitive tiredness takes its toll, you can work on easier and less critical tasks. Lastly, as a team, all members should not just together prioritise the tickets but also strictly follow it.
If you have similar experience or observation, please so kind to share your story in the comments.
The article is also posted on my blog.