Is it Expected to Work Overtime in a Startup?
In IT, people quite often have to deal with overtimes:
- a project has swelled out of proportion;
- someone got their estimates wrong;
- the client has an important deadline;
- we have to test our MVP fast;
- a competitor has this feature…
While it can be an opportunity for additional compensation or greater schedule flexibility, I’m convinced it’s never a good idea in the long-term.
We do not practice overtimes at Everhour although we serve more than 3,000 companies from 70 countries.
Like other companies, we are growing, have to solve scalability problems, we experience bugs and downtimes, constantly release new features. But still, we have enough time for everything. There are 16 people in our team now (while there were only 7 last year, when we reached our first significant milestone — $1MM ARR)
In our case overtimes aren’t very common. How is that?
The first reason is our phase and financial stability. Our product is profitable and we did not take VC money, that surely takes off enormous pressure. So, pay great attention to finances.
However, I do not consider this as the main and the only reason.
I can easily understand overtimes in outsourcing business, when there is an “external” customer who often has a deadline or when you as a manager intentionally assign resources on multiple clients to increase profits or undertake new projects to avoid idle time.
But startup is a different story.
It is very difficult to produce even 6 hours of high-performance work per day, not to mention overtime. Try to work honestly for a while at this pace. What’s the point of just having an employee in the office long hours? If the employee does not produce a tangible result during normal hours, this is kind of cheating, procrastination or not ideal task management.
Overtimes are symptoms of some problem that you need to eliminate.
Without a good work-life balance, people do not have enough time to relax physically and mentally, they come exhausted to work and show not the best results, let alone burnout and even serious health problems.
I have a few simple pieces of advice.
Timing Isn’t Always As Important
The task can take longer due to various changes and enhancements. Be focused on results. Each new feature or change should provide benefit and appeal to users. You never get a second chance to make a first impression!
Split an Epic into Chunks
Whenever possible, try to break up large tasks into smaller ones.
They are easier to estimate and faster to make. Large tasks obviously take longer and have a much higher bug rate. When an employee hangs for a long time on one task — the excitement is lost. It is no longer interesting, and every day you have to force yourself to work on this task. We all love to do something new.
It also creates a feeling of progress. People like to accomplish something. Give them this feeling more often.
Be More Realistic in Planning
Don’t schedule 8 hours of work a day. Everyone gets distracted, some unforeseen circumstances and tasks always pop up. Plan a little less, say 6 hours.
Describe Tasks in Details
Describe tasks in great detail. This will save time on misunderstandings and the need for additional communication when the task was already started.
If all the nuances are clear, any developer will do everything faster and better. Do not be lazy, do not think that everything is obvious here. Furthermore, a detailed manual will be useful for QA and support staff.
I highly recommend reading the latest book from Basecamp founders — “It Doesn’t Have to Be Crazy at Work”. Good non-conformist view on the topic.
