How to start to burn, but not burn out in a project where “it was urgently needed”
Perhaps this opinion will seem unpopular and even strange – but since then I do not want (and cannot) work differently. I love it when development is at a super fast pace. I realized that I want to get high. But I don’t want to burn out anymore. And I began to build protection against burnout: let me tell you what happened and how it helped me and the team in quarantine, when we had to work in a “sprint in a day” format to help schoolchildren.
To start burnout, you need to repeat a simple cycle several times.
Here you figure it out, fight with bugs, deadlines, get high on what happens. You see the result, you feel the return, you want to do something beyond what you have. Then someone comes and says:
– We do THIS in a week!
– It’s impossible.
– Next Monday I need to go to production.
– Ok, let’s see what we can do.
Usually, “this one” means either a completely new project, or some new feature, which is not always included in the overall concept of the project, but should become key. And you take a task for the weekend or sit up in the evening.
It happened at a medical startup. At some point, we decided to take a course on b2b. The customers were private clinics: at that time, the site with the excel-price list was for the majority the top of the digital, but we offered a “combine” with personal accounts and end-to-end integrations. At the same time, each clinic wanted something that others did not have, and this something had to work and look “just the way it should.” Neither the customers nor we often knew exactly in what form everything should be. But it was important for us to release finished features as often as possible.
The development was like short contracts. In parallel, the legislation was changing. We couldn’t afford to forecast too far.
Every day we said that this is not possible, that we need sprints with clear plans, but … in the end we accepted the importance of quick changes, learned to do more and enjoy it. And a year later we got used to this rhythm.
The idea “you work not because you work, but because you want to” has become a credo. The problems started later.
When you realize that this is a thrill, you start working almost always when there is time and mood for it. It takes your strength away. At one point you can catch yourself thinking that you do not know how to take and turn off this part of your life. If you take a week or two off, you won’t be able to do anything useful. And in general, how can you rest here while everyone is working for a good cause? At some point, you start to think that you can do it without rest. But this is cheating 🙂
After working in this rhythm for several years, I quit. By the last months, everything has been disgusting, including thinking that I no longer want to write code. In an attempt to escape from myself, I tried to be a project and a team lead. I tried to “go to Asia to lie on the beach”, but could not concentrate on rest, returned two weeks later without rest.
After a few months, I could write code again. Turned out to be in a good location. But this was not a startup: tasks that could be done in a day took a week, and meetings and acquaintances with other departments ran counter to the already formed habit of working constantly.
I began to bother that I didn’t bring results. And again he began to look for himself.
The story of how to figure it out, but not burn out
I’ll start from afar – last summer Skyeng relaunched Skyes: a b2g service for schools and universities. In short, they bought access to the system, and their teachers received a personal account in which they could send homework to students based on the material of the necessary textbooks.
I liked the beginning: the project had to be launched in a month. We made it in time, but then everything went pretty sluggishly – the specifics of the market, and a bunch of other moments emerged. It was March 2020, I decided to go on vacation and after the end of the school year I started looking for a new project, as I started to get bored.
And then a pandemic came: my vacation was declared a non-working week, and schools were transferred to “remote”. A couple of hundred thousand schoolchildren came to the site of our project. I remember how I woke up from a call from the infrared – Skyes does not hold the load.
At the same time, Skysmart was invented in the management. In short, the company had several projects aimed at schools: the idea came to “glue” them, adapting them for quarantine. Basically, make a binding around our main Vimbox platform, adding school materials, easy and free access for teachers and students.
It was decided to urgently migrate our project to another – and so I again fit into the fever of a startup.
Let’s tell you how and why we worked:
- There were not many goals, but all seemed transcendental. The main objective of the new project was to collect the maximum audience for the remaining two “school months” – it was about millions of schoolchildren and ten million homework completed. At the same time, in the course of the project, some of the goals changed upward.
In short, we made a simple homework generator that saved teachers hours of coming up with and checking work, and children and parents – time and nerves. You can read more in this habrapost.
- The first weeks worked 12 hours a day. Then it was gradually reduced to eight. In the first weeks, they did something on Saturdays. Then we went back to five days and introduced a “subbotnik”: just a day during the work week, when we deleted the code, refactored, and so on.
- Every day is a sprint with planning and demo. Every morning we discussed new features, in the afternoon we understood what part of the tasks would reach the sale. In the evening at the demo, the development showed them. We had a ban on deploying from 9 to 15 o’clock, when the bulk of teachers and children came to the site, so sometimes they did only the “core” of the task, and sometimes they stayed up: it seems, when we just launched the leaderboards, we sat until midnight, so that tomorrow everything worked.
Once a team of researchers asked schoolchildren to draw how they see our platform – it was funny. Feedback from users motivated to “figure out” day after day.
Two months later for the last time we shouted to each other on the demo: “Well done!” – and went to rest for a week with the whole team. Everyone was so damn excited on Friday – a corporate at Zoom, memories of how it was. And then the most interesting thing happened.
It’s hard for me to compare burnout with anything, but it probably happens with athletes: when you go to the goal for a long time, then devastation sets in.
The first days it is very difficult to force yourself both to rest and to do something – to the point that there is no strength to meet a courier delivering food.
But I managed to overcome this condition in two days. Then I went for a walk, “tasted” the weekend and did not blame myself at all for not working. At the same time, I got my buzz from the amount of work that I did, and fatigue and “phase shift” were minimal. But I’ve been through this before. I knew how I would react, and that such a reaction is normal. Most of the guys didn’t have this experience.
However, a few days later, it became clear from the correspondence with them: the guys are beginning to give themselves permission to “lower down”, cut through the reward chip and go to look for tangible gifts for themselves and their relatives for 2 months of the marathon. Or somehow they start to cope and come back to normal.
It may seem that we took controversial practices and this somehow gave a result. I think we groped for prototypes of good processes.
Of course, the conditions of our “experiment” turned out to be unique – with the quarantine, we could not be distracted by cafes and restaurants, visiting, traveling somewhere on weekends. Therefore, “work hard” was a reasonable way not to go crazy within four walls.
But comparing the experience of a medical startup, where I left for six months, and an educational startup, where I left for a week, I realized one thing: it’s not possible to not burn out at all, but the degree of “burning” can be regulated.
Goals can be ambitious and change upward, but break their achievement into stages – and calculate in advance. In our case, each of the goals was somehow calculated by analysts with an accuracy almost up to date. And then it is broken down by gradation: not just “get 10M completed tasks on the platform in 6 weeks”, but “do 100K in a week”, “do 1M in two”.
These landmarks helped to turn on the head more often and do only what was needed. Plus, only the metrics that were achieved halfway were revised.
Our designer started an open Slack channel, where he wrote his mood in% every day. For fun, I’ve deduced the correlation. There she is:
May 30 is the day we finished the project.
Sprint in a Day was a good solution in the face of tight deadlines: it was important for business to experiment a lot and quickly change the product under the influence of the audience, while there was demand for the product (and it fell sharply with the beginning of the holidays). The tasks had a short time to market. Therefore, in order to drag the task to the demo, it had to be small and clear to everyone.
This led to the following laws within the framework of the day: a minimum of bureaucracy in discussions, but each task must be clearly evaluated.
Every day we tried to find the best solution in discussions with design and marketing. This gave a high level of trust between departments and within, as well as maximum immersion of each participant in the process.
If we from the development side could not decompose the task into understandable and measurable steps (create entities, migrations, getter, test), it became obvious that something would raise questions.
Usually, problems that were completed in 4-5 hours fell into the category of incomprehensible. They agreed to decompose and only then take them to the sprint. It is better to admit right away that we have three tasks for five to six hours each, than then wonder why “the round for eight hours took so long” (here is a good post from a colleague on this topic).
As a result, we got a much more manageable set of tasks. We saw progress more often. And, if necessary, parallel the work. Even the demo on sale gave motivation to make the features hidden behind the config. And also very quickly fix what was breaking) The results gave strength: in the mode of tight deadlines, it is very important to observe them as often as possible, to visualize them.
But the main thing I realized is that challenges are destructive in the long run.
The challenges are for yourself. The calls bring the team together. But to rise to the challenge and not burn out, you need the necessary conditions in the form of a culture and a team that shares it. They should be cultivated on an ongoing basis. Because “startup mode” is either accepted by people or not.
But your overall task will be to get out of this mode quickly.
Define your run boundaries. In the case of my first experience, the challenge mode became a part of everyday life: fatigue accumulated gradually, but at some point it “pressed down” for six months. In the case of a quarantined project, the general limitation of 2 months created a picture of the world in my head that did not need to be fought, as it happens in a constant “need yesterday” mode. Another thought sat in my head: “I know it will be over in 2 months. I know why I’m doing this. It is my choice”…
As a result, it will not work at all not to burn out. But you can get burnt and quickly move away. To do this, when you fit into the game, you need to understand what it is for. And the longer you play, the more you need to confirm that this game is not just that.
