Flexibility in work - remote work and working hours that are not fixed are default for most developers, so companies are expected to include this way of working in their daily routine.
In order for this approach to work in practice, it is still necessary to establish a minimum of certain rules that should be followed, i.e. minimum limits, as well as carefully determine and plan goals. How do IT companies achieve this and how does it affect development teams and individual developers?
In the text that follows, we will use specific examples to bring closer the way of thinking that guides companies to achieve the most flexible work environment possible, in every respect. Sergej Grivcov, Senior Director of Software Engineering at GoDaddy, guides us through them.
Sergej Grivcov, Senior Director of Software Engineering, GoDaddy
Maximum reasonable flexibility
An ideal set of rules sets the fewest limits, yet achieves the essence. That may sound too philosophical, so it is better to formulate the following question: "Why limit something that does not need to be limited?". This is what guides me when it comes to how to organize development teams, Sergej tells us at the beginning of the conversation.
He got the opportunity to go in search of minimal restrictions back in 2015, when he became the manager of the entire engineering team of the startup Devana. He continued on that path when they were acquired by GoDaddy in 2016, where he is six years later. What has he learned in the last eight years and how has it been reflected in the principles that guide development teams?
Clarifying this, Sergej starts from the general question of what the company's goal is when hiring a new person in the development team. To have one person more than 9am to 5pm daily? The answer is certainly - no.
The goal is for the employee to achieve better results than he/she could before. The bottom line is the results, not the time spent on the job. Therefore, the usual rule that working hours are from 9 am to 5 pm, sets a great limitation and does not achieve the essence.
Fixed working hours, however, make sense when it comes to jobs that are done in shifts because then the required result is exactly the coverage of the shift. However, when the company's focus is on software development, Sergej points out, it is not something that is usually done in shifts. And this is where the increasingly popular regime of flexible working hours comes into play.
What is flexible working hours?
Companies call the most different things flexible working hours - from starting work between 7 and 9 in the morning and staying for 8 hours to more radical approaches where almost nothing is defined on the topic of working hours. There are also solutions "Come whenever, but the mandatory daily meeting is at 9:30".
In order to set as few restrictions as possible, does it make sense to have no rules regarding working hours? The problem with this approach, says Sergej, is the fact that it will still damage the team's results, which are the goal, just with as few restrictions as possible.
In every team there is a need for communication between team members to transfer knowledge, come up with solutions, understand where they are in the project, etc. In response to that problem, we have defined overlapping times when all team members are expected to be available. This is also the time when meetings are usually organized. Each team defines that time for itself, in relation to the needs and wishes of the team, and the middle of the day (12:00-16:00) turned out to be the most frequently chosen time - says Sergej, adding that this does not mean that everyone always has to be there at that time at all costs. It is enough to report an absence, as long as it is not something that happens every day.
Apart from the rule that there must be some overlap during the day, they have no other rule.
As long as the results are there, we don't track how long someone will work. And, if the results are not there, we will not talk about how much time a day he should go to work, but why the results are not there. Over the years, this has proven to be the best system, which really doesn't have many rules, and achieves all relevant goals - emphasizes Sergej and states that this principle has also proven to be very useful for working from home.
Therefore, even when the pandemic began, they did not even feel the change in this segment of the organization. Today, a large number of employees work exclusively from home, according to their own wishes, which has become a standard option.
All this sounds great, however, when trying this approach for the first time, there is a need for good definition and planning of goals. Sergej explains why.
In a system defined in this way, he states, the lack of goals is the equivalent of working time of 0 hours - all results are met and there is no reason to do anything. The other extreme is if the goals are too ambitious - that is the equivalent of working 12 hours or more, and the point is not that people end up working more than the classic working hours (8 hours).
Previous experience has shown that the key to success is understanding what the goal is to achieve in a future period at all levels. What is success at the company, team, individual level? There needs to be one image that all employees share. If the goal is variable, undefined, or unclearly communicated, it is difficult to objectively measure success.
How to set realistic goals?
Sergej states as an example that if an engineer does ten tasks, and it is not agreed in advance whether it is a lot or a little, and even more importantly, whether these are tasks that are important at all - it is not possible to know whether it is a good result or not. If you ask an engineer, they will probably say yes, but if you ask a manager, business owner, or someone else, the answer will probably vary.
In our company, this looks like setting general goals for that year for each segment of the company. Then it's broken down into quarterly goals. Finally, the quarterly goals are converted into engineering sprint goals. The idea is to come up with goals and initiatives at each of these levels that bring about a result that everyone is happy with and that can be achieved in 60-80% of the allotted time.
So in order for something to be defined as a goal for a two-week (10 working days) sprint, it must be something that is thought to be completed in 6-8 days. Errors are reasonable in the range of up to 15%. If estimates are consistently missed by 30-40-50%, then we should work to make them better.
When things work as they should, goals are regularly met and everyone is very happy. Sometimes there is even room to do something extra. For that, goals are usually defined that we don't expect to be able to fulfill but guide us towards what to do when the basic is achieved.
When the teams work together, this is an example of a system that can be very effective. However, even then it can be difficult to implement the system. Relatively recently, says Sergej, they had an example of such a situation...
Namely, they inherited a ten-year-old project, which is still active and brings a lot of money to the company. Besides being old, the problem is that some parts stop working in different situations. This led to the fact that in the first week, the team had to react to incidents even in the middle of the night, otherwise, the company managed to bring all the projects they are actively working on to the level of having a problem possibly once a year. How did they solve this challenge?
First of all, we agreed that no one should spend more than 8 hours a day working. Unable to plan, we had to fall back on time limits as a temporary solution. After that, we dedicated our time to finding the problem, the solution of which will reduce the frequency and amount of problems the most. Finally, we agreed that any patch that solves the problem and does not create a new one is acceptable, even if it is not a fundamental solution.
This, concludes Sergej, was a way for them to get back to a stable situation and regain control in the short term, so that they could ultimately rely on the coordinated ways of planning described in the previous lines.
Flexibility in every way
GoDaddy's goal, like most IT companies today, is to strive for flexibility in every way. Such a working environment is imposed by the market, but also by the company's culture.
If you are interested in learning more about working in this company, check their profile on Joberty or check the currently open positions they offer.