Why delegating responsibilities is better than distributing tasks
Trust is the highest form of motivation. It brings out the best in people.
Stephen R. Covey, The Seven Habits of Highly Effective People
In fact, today it has become the sacred mantra of project management: divide work into tasks as small as possible… Rate them with your team. And then drop them into the all-knowing product backlog. However, no one seems to have critically studied the impact of this approach on the software engineering profession. In the 90s, when I started programming, we worked differently. I dare say that it was a little more professional back then.
In those days, your boss was responsible for a dozen or more tasks, so when you were hired, he could breathe a sigh of relief.
“Finally, we have Vincent, I can instruct him to take care of A and B; Ted will do C, D
and E, Jen will handle F, G and H, and I can get to I, J, K, L and M. “
The most important thing here is that A and B were large tasks, for example, whole products or large system libraries. It took all your time to create and maintain them. They were delegated responsibilities, not just tasks. It was also easy to manage people. If you are not doing well, the boss will tell you about it.
“Vincent, work on problem A is not going exactly as I imagined. You can do a little better. “
Then you went back to your personal office (I miss private offices, but that’s a topic for another post) and corrected your mistakes. Later, at a weekly planning meeting, you talked about how it went – yes, without any daily five minutes in which you sadly look at the floor and admit that you have not yet made any significant progress.
There was no fiddling with backlogs and burnout charts either. Your boss just looked at how things were going your products. A little trust, a little accountability, and a fair amount of “freedom to do your job.”
We work differently today. Alas, the process has become less motivating, less effective and it takes into account individual skills much worse.
So whose vision is this?
In my opinion, the division into small tasks was born from a fundamentally different approach to leadership. Small tasks are a fairly straightforward way of showing that management is responsible for the entire product vision. Move away and don’t touch.
Big tasks send a completely different signal. In this case, management gives you a more serious job, inviting you to invest your own creativity in the final product. You manage to take part in the design, think about the needs of the customer, feel pride in the result of work. Of course, the organization is guided by its own strategy, but it still strives for people to take responsibility, rather than follow orders. She believes that you will be guided by a shared vision, and you do so because you want to be part of the “club”.
Too much love for metrics
Small tasks have taken root also because they fit well the mentality of the “assembly line” that has developed over the century. Unfortunately, there are entire armies of managers who still live by this dogma. For them, the whole point comes down to selection of metrics and their optimization – to control by means of graphs and diagrams.
Unfortunately, small tasks in Jira (or any of dozens of other bug tracking systems) bring with them the prospect of a whole host of delicious new graphs and charts: burn down, burn up, velocity, lead time, cycle time, task age, throughput, failed deployment, flow and control. All this beckons like candy beckons a child.
Assignment of responsibilities instead of tasks takes away from the assembly line manager his favorite tools. Due to the larger size, the charges are not easy to measure and track. Therefore, metrics managers will fight to the last drop of blood to keep work divided into tiny, traceable instructions.
When will I be able to gain design experience?
Unfortunately, we, as developers, tend to do this too. As soon as we are promoted to a better position, we immediately get down to business with a ready-made program. When the average developer might have the opportunity to do research or design, we instantly take over that task.
As a technical lead, we standardize frameworks, languages, operating systems, and cloud service providers. We write wrappers for networking, logging and monitoring libraries, and require that they be used at all times. Then, taking the risk of designing and researching the CI / CD tools and pipeline, we write coding standards for our coding standards.
Even worse, we design the architecture of each project and expect that any deviation from it must first get our approval. For others, we leave tiny pieces. Routine work for the infantry, from which everything interesting was removed.
Poor programmers, working on the very front of work, have nothing left, they ask: “Sir, please, can I have some more? I just wanted to design one small service. I know I’m not worthy of this, but please, can I just write my own sql queries without this awful ORM? “
Alas, when these poor programmers finally wait for a promotion, hoping for their first real opportunity in a higher position, they are denied: “I’m afraid you have no design experience. We are looking for someone who has already designed large systems. ”
They can rightly say to their managers: “It was your job, not mine!”
Assessment always requires resources
There is a serious misconception that if you just sit in the comfortable chair of a conference room, divide the project into tiny tasks, each of which can be evaluated separately, and then add them, then voila, you will have an accurate assessment of the entire project. Lighter than easy.
However, this illusion has two problems. First, no task, even the smallest, is easy to evaluate. I have often seen “tiny” one-day tasks that grow into weekly campaigns. This was due to the hidden complexity that falls out of Pandora’s box after you start coding. Secondly, when you divide work into small tasks before you start working on them, you make unverified assumptions. And there are a lot of them. The more tasks you define, the more facets of the hypothetical architecture need to be assumed (of course, indirectly, because no one specifies the assumptions in the task descriptions). Soon you will have a long chain of leaflets on the wall, each of which depends on the last.
The problem is, once you start working on one of them, you realize that the implied design decisions are wrong. Now you need to spend MUCH more time than the previous task assessment, and all other tasks depending on this erroneous decision will be invalid. The whole house of cards will fall apart. Is it time for another day of messing around with the backlog? What a waste of time!
Back in the days before we realized that software companies had to make a lot of money, we had room to maneuver. We had a lot of responsibility and the ability to make many decisions. But today many more people have come to our land. Unfortunately, some of them have gradually destroyed the software developer’s realm of opportunity. One by one they descended from their ships and hoisted their flags:
“I am Amerigo, Product Manager. Therefore, no developer will make design decisions, because this is my domain. “
“And I’m Fernand, process manager. Therefore, no developer will make decisions about the organization of the process, because this is my domain. “
“I, Bartolomeu, will ensure compliance.”
“I, Vasco, knew a lot about Microsoft Access, so I will probably be working on databases.”
One by one, the developers were stripped of all responsibilities except the responsibility to “open emacs and start writing code.” And then the remaining purely technical tasks were selected by architecture designers and standards engineers who were greedy for essential tasks. Only dried, crushed shells remained on the ground.
Of course, there is a way out of this difficult situation – to delegate duties everyone, down to the bottom of the hierarchy. Or even better, flatten the hierarchy, or even get rid of it entirely. But until that happens, we have to settle for pathetic for loops and if statements. Of course, they meet all coding standards.
VDSina offers powerful and inexpensive VPS with daily payment. The Internet channel for each server is 500 Megabits, protection against DDoS attacks is included in the tariff, the ability to install Windows, Linux or the OS in general from your image, and also a very convenient proprietary server control panel. Try it!