Due date as a component of responsibility in the development process

The issue of efficiency is always a highly relevant one in the sphere of product development. How does one put together an optimal workflow in terms of business objectives, employee growth, and many other factors, while ensuring that it’s modifiable and transparent? Where is the “silver bullet”, which will solve all the problems at once and spare you a number of managerial headaches?

And it’s great if people can formulate the needs that they want to satisfy through this or that process. But oftentimes, a fashionable approach is implemented without much thought, which eventually proves inefficient or dissatisfying to various participants. And in this day and age, with its high velocity and the proliferation of start–ups in a highly competitive environment, such imprudence can prove disastrous for the business.

Let’s consider what’s required of the process, what problems need to be solved, and what approaches are adopted to accomplish this. And I’ll tell you about how we do this at Badoo. I’m Ilya Ageev, the QA Manager at Badoo.

Various company employees involved in making a product come to work pursuing a variety of individual goals. It’s good if these goals can be balanced and good business performance can be attained by using joint efforts. It’s obvious, however, that the business and its individual employees don’t have the exact same goals and values. Someone may be saving up for a house, a new car, or a vacation. Another person is motivated by stimulating collaboration with others and personal development. Businesses are focused on earning money and regard their employees as resources that enable them to achieve their goals.

I think we can all agree that few companies (if any) exist for the sake of paying wages to their employees out of the sheer goodness of their hearts. Company goals are different from those of the employees and not always shared by them.

And it seems to me that in this complex symbiosis the company’s goals ultimately take priority over the goals of individual employees. A good company appreciates and loves its resources, but from the business stance, a person (like many other resources) can always be replaced (although it may sometimes be very difficult). One way or another, global goals are not subject to change. And it would be odd to expect this from a business. “How about instead of baking bread, we’ll now start giving musical performances at children’s parties!” On what grounds? If it’ll increase the profit and is easy to implement, then let’s. But no one would go for changing the direction of the business just because baker Volodya loves to sing (and might quit if he doesn’t get to do it soon).

Therefore, the first and most important participant in the production process is the business itself. Since it picks up the tab, it makes sense that it gets to call the shots. What does the business want? The goals may run the gamut, from charity to employing family members (yes, this happens too). But in most cases, the main goal is to improve the welfare of its owners. And preferably do so in the cheapest way possible. “How to spend less and earn as much as possible” is the engine propelling forth the free market.

In our production process of developing features, the business is represented by the product manager. His/Her job is to understand the business objective, formulate it, relay it to the developers — spoon-feeding it to them if necessary — find a compromise, and plan everything out competently. After that, he/she monitors the process, checks the result, and launches it into operation.

His/Her goals are obvious: to get as much work done as quickly as possible, allowing time for experiments, testing the viability of ideas, fixing any possible flaws, and starting to earn money on the product as soon as possible (I’m intentionally omitting the notion of quality, but it’s implied: no one will be buying a sub-par product).

Therefore, the product manager constantly inquired into projected time frames, surveys the current status, puts pressure on the other participants in the process, and seems to want everything done at once. He’s/She’s just trying to figure out how to do things in the most efficient way possible and, ideally, how to accomplish even more and do it faster next time. This is as it should be and a good approach from the business standpoint.

Ideally, all team members would grasp the importance of the process, be very motivated and careful throughout, and always succeed. Is this possible? Not always. Especially when it comes to clarifying and sharing common values. But I’m confident that a compromise can always be found if we make sure that the subsequent participants in the process aspire to meet the deadline, focusing on some simple indicator and guided by simple rules.

In our company, the Due Date serves as this indicator. I’ll also tell you how we try to ensure that the developers themselves are striving to achieve the set business goals.

Who’s the next participant in the process? Baker Volodya. In our case, a programmer. What goals can a regular person have, even if we consider that the average IQ in our industry is quite high? Earn money and go to Bali, buy an apartment, save up for his old age, pay a loan, buy a Gibson, leave work early tonight, go to the cinema, and meet a good-looking girl next door. And since we’re talking about an IT crowd, let’s throw in a few more: unload some of the backlog at work, replicate a pesky bug and thus get a break from the boss’ quibbling, learn Erlang, feel around the new Python framework, learn English, assemble a drone on Raspberry Pi, and listen to the podcast about the advantages of Kotlin.

Of course, there are some great employees out there, who genuinely “root for the project” and “understand the business” — after all, we’re all in this together, working for a common cause. But try to leave them unpaid once or twice (I’m not trying to offend anyone — just painting the picture in broad, exaggerated strokes to illustrate my point). What would happen? They would go to Yandex, Facebook, Google, and any other company offering generous salaries, free lunch, and bonus perks in the form of massage and mani-pedi. And they would be right in doing so! Workplace is where the business buys the labour (and brains) of its programmers in exchanges for monetary compensation and is thus based on fiscal relations. And while the goal of the business is to get as much work as possible for the least amount of money, the employees have the opposite goal: to do as little as possible for as much pay as possible.

Of course, there are also other participants involved in the process: designers, copywriters, translators, analysts, testers, release engineers, sysadmins. But firstly, their goals don’t differ much from those of baker Volodya. And secondly, they often play auxiliary, rather than leading roles, covering for the primary troops — the developers — while they charge forward into battle. By the way, some of these job positions may not even exist in this or that company: they are often combined with other roles. In product development, all such personnel act as resources for production managers and programmers, facilitating their job, taking care of routine busywork, and so on.

So, the programmer is the second most important participant in the process after the product manager, who represents the business. Baker Volodya may choose to put all of his time into work if something sparks his interest: he may not sleep or eat or go outside. But a business process spans a wide range of tasks, including many boring and routine ones. So, if Volodya has completed ten tasks that are of interest to him, but not for the business, and only one boring task that’s crucial for the business, it’s tantamount to him having completed only one task. The business’s prime objective is to sell manufactured goods at a competitive price. What technologies are used in the process and how ingenuously Volodya implemented algorithms and baking tricks are all issues of rather secondary importance.

Of course, Volodya doesn’t want to know about any deadlines or coordinate with the product manager, designers, and accountants — he just wants to sit down and immerse himself in his interesting task (with no one interfering). And in these conditions, deadlines, plans, customers, and competitors — all comprise harsh reality, with which Volodya has to put up, but don’t serve as part of the strategic goal, as in the case of the product manager.

This means that the developer himself is in charge of setting the deadline. Of course, he must do this by carefully examining the problem and trying to take into account as many factors as possible in his planning. And of course, he should strive to meet this deadline. But we need to be prepared for a possibility that the developer may fail to meet the deadline. What matters is how to proceed: we consider every nuance that prevents us from meeting the deadline and prepare a response to it (so as to ensure that next time this problem can be avoided).

It’s the developer who should be required to give an answer, because he knows the project better than anyone else. He has set the deadline this time, and he will set it again in the future. He may get it wrong again — that’s OK. The important thing is that this approach improves the engineering culture and stimulates the growth of the developer and the company as a whole. And it’s obvious that a dependable solution needs to be found on how to avoid such problems in the future. Not just to “try to do better next time,” but make it so that it doesn’t happen again, minimizing the human factor as much as possible.

It would be nice if the technical manager upon receiving the Due Date and confirming it would not take his attention off the project until just before the deadline, for that’s risky and postpones the solution of many problems till the last stage (problems that are easier, faster and cheaper to solve immediately ). Instead, the technical manager should periodically check in on each task at agreed upon intervals (so as not to distract the developer from his work) and get an update on the situation, correcting the time frame as needed. A need may arise for a compromise decisions that allows for the deadline to be met, but leave some “polishing” and fine–tuning improvements to the functionality to be done in the future.

It’s also worth mentioning that simply pushing the deadline by an n number of days is not the best solution. How can it be controlled? It’s very simple: the tasks completed before the deadline should also be considered incorrectly planned out. Note that “incorrectly planned” doesn’t mean that everything is bad and the developer should be punished — it just means that it should be noted and brought to the manager’s attention, and the problems that have affected the time frame should be discussed (these may include “creative ecstasy” and unexpected finds during the development process).

It’s vital to grasp the essence of this: we are not striving to just make everyone observe the Due Date. The development of a feature process (unlike that of baking bread) inherently includes too many uncertainties. Very few tasks are similar to one another: there are no “universal” bread loaves. If the baker failed to do his work on time, it means that either there was a force majeure (the bakery lost power, flour wasn’t delivered on time, etc.) or he is just lazy. On the contrary, in development, it’s rarely possible to meet the deadline, even if one tries very hard. So if the developer didn’t meet the deadline, it doesn’t mean that he screwed up somewhere. The heart of the matter is elsewhere: we look at the reasons why the deadline wasn’t met and evaluate the contributing factors (what affected the time frame: the situation, resources, human laziness, or lack of understanding of business goals). The developer can be very productive, but constantly distracted by minor things that may seem important to him because of the lack of proper focus on the result, (or, alternatively, because we took some time off working on his task to help Vasya down in Shipping, because they’re chums). As a result, the developer may have many reasons that he sincerely considers important. Meanwhile, the result is missing. Here, the manager is called upon to provide ongoing support and adjustment.

So, let’s summarize.

1. The developer sets the deadline for the task in the form of a Due Date. This is the time when the task is supposed to go into production.

2. The technical manager must confirm the Due Date. It would be nice if he did this after first examining the project for himself and immediately pointed out the factors that might affect the future timing. Coaching should start already at this stage.

3. The manager must check on the status with the developer at certain points stipulated in advance: to consider the problems that may have already arisen and the processes that can already be accelerated. Example: “Why did the review of three lines of code take three days?”

4. After the completion of the project, no matter how it goes, a retrospect should take place centred on the question “How do we do this faster next time?”

The Due date is an optimistic forecast. In our company, everyone understands this and knows that the developer needs the manager’s support at all stages of the project. And even if we assume that the developer will have a small surplus of time, which helps him feel more at ease and confident, there’s nothing wrong with that. Our goal is to do things effectively and pragmatically, and not drive anyone into the ground, because we have to keep working together on plenty of cool projects.

The following situations can be considered as examples describing good and not so good solutions. Obviously, these solutions are not the only right/wrong ones, but I hope that the essence is easy to grasp.

1. The task was reopened too many times, because the testers kept finding a lot of bugs, which led to unnecessary time costs in all the adjacent stages: context switching, waiting for the task to make it down queues, etc. A bad solution is to yell at the testers, fire them, and hire new ones. A good solution: cover the code with unit tests, in order to receive feedback about the quality of the code faster next time; work on methodologies and practices to improve the quality of the product.

5. We did everything on time, but two days after the layout we found out that a very important component of the system has been broken by new code. Users could not use the product, and the feature had to be rolled back and repaired. A bad solution is to punish developer and testers. A good solution is to start monitoring this and other important components of the system, cover them with autotests, and complement new features with at least minimal statistics on proper functioning and basic business indicators.

And it’s good to remember that there should only be one person in charge. Even if there are several developers working on the project, one of them should be responsible for coordination and staying on schedule. Often, this is the most experienced developer on the team. This way, we try to avoid a situation of collective responsibility: after all, if everyone is responsible, then, essentially, no one is responsible.

At Badoo, we also practice the approach where we put in charge not the most experienced, but the youngest and most enthusiastic developer — in order to stimulate his or her growth. In such cases, experienced developers observe all phases of the project and assist in every way by advising and point out mistakes. And even if takes longer to develop a feature (although this doesn’t have to be the case) and increases the number of risks, such an approach is strategically wise, since it fosters the growth of people in the team.

In addition, there are a lot of factors that affect the developer’s motivation and stimulate his understanding and adoption of the company’s business goals: business prospects, understanding the project’s importance for the company, desire for smooth implementation and operation, subjective satisfaction with the customer, etc. A lot of this is difficult formalize and measure. And it’s even more difficult sometimes to convey the value to a specific performer. Oftentimes, even a very good developer doesn’t notice when the product trends change direction and needs some kind of clear and simple mechanism that indicates the right direction.

Accordingly, I consider the Due Date as one of the main tools for stimulating the developer’s IER at all stages. It goes through the whole process and makes it necessary to invent solutions to avoid a ton of problems in the future. It allows us to delegate responsibility without resorting to multiple KPIs. It’s comprehensible and accessible to almost everyone. And it guides us all towards the key business goal: to making as much as possible as quickly as possible. And whether it can also be done cheaply depends on the solutions that we use, and therefore, on all of us.

And how do you do in your company?

Related posts:

Thanks to companies like Squarespace. While you no longer need to write or read code to build a modern user-friendly website… Here are the 31 foundational web design best practices that inform my…

Logicism is the proposition that the foundations of mathematics are logical. Logicism has been viewed as unlikely by modern mathematicians for its inability to prove the axiom of infinity. An axiom…

6 out of the top 10 pharmaceutical companies belong to the USA. Most of the pharma companies around the world prefer to launch their drug in the USA first. The reason is simple. The USA allows pharma…