why cultivate a technologist in yourself?

I once wondered why some QA engineers get stuck in middle positions, while others rise to CTO. I researched this topic, conducted interviews and came to certain conclusions that I am ready to share.

Disclaimer: wherever the term “testers” is used below, you can substitute “developers”, “analysts” and even “managers”, because skill nutrients are generally useful for all IT specialists.

I’ll start from afar: in the Soviet Union there were technologists, in the Western world there were engineers and inventors. These are the guys who launched and debugged the processes. Why is this important? A good example is Henry Ford, who did not invent the automobile, nor did he make it the first, or the best, or the most suitable. But he made it popular. And he achieved this precisely by building processes and introducing a conveyor for one of the types of their debugging.

It was Ford who invented the I-process – the linear flow of automobile production. Interestingly, he made one model from the same spare parts. And even if I changed the model, the spare parts were compatible with each other – like Lego parts. It was really one stream, one pipe in which everything was collected. And, most importantly, how this process was built. All competitors had large warehouse and logistics costs: they manufactured parts, took them somewhere, they rusted there, they were brought back and cleaned, and sent further. Naturally, all this affected the economy.

And Ford set up so-called buffer zones at the junctions of its production chains, into which it stored products. And if this intermediate warehouse was filled to a certain level, work on the previous lines stopped. Because he didn't need overproduction. Instead, he wanted to quickly pass everything through the flow. This is why technology was needed: to build such a process, a flow of tasks that would provide maximum economic benefit.

If we look at software production, we will understand that it also has its own flow. Tasks are created, processed, transferred to development, tested, rolled out, supported, and so on.

The trick is that most of these processes at some point begin to be initiated by a person with the skills of a technologist. Unlike others, he looks at the process as a whole, and not just at his own piece. For example, a developer received a task, he coded it and sent it to testers. And the testers received 25 more tasks that day, simply because the developers decided to take one task at a time, worked on them for two weeks, and finally sent them to the tester at once. But he cannot test 25 tasks in a day.

And at this moment the skill of a technologist appears on the scene, which allows a person to look around, see the imperfections of the process and correct them. And if you see in a person the makings of a technologist’s skill, then with a high probability this person will grow further.

Say a word for the poor Junes

Testing is a fairly small area where theory and experimental techniques are used. But to a technically trained person, testing can be explained in three hours. If you take a couple of glasses of beer and sit a future tester in front of you, then the entire testing theory and even part of the practical application can be explained to him in about four hours. Because there aren't that many basic skills you need to have.

It's about the same story with developers. A junior developer does not build architecture and does not write down business solutions. It doesn't do anything except pass JSON or simple calls. And if he doesn’t have documentation, but has 25 urgent tasks, then he completely loses the ability to work and shouts at the table.

With junior managers and analysts, everything is exactly the same. They have only a narrowly focused area of ​​their specialty. And now we have a game dev guy – and at the interview he is told to write “The Troubles” alone. Or a novice engineer is given two coils of wire and a hammer and asked to build a synchrophasotron. At the same time, when hiring a junior, they actually expect him to transfer JSON. Moreover, exactly those who said and where they said. If you, when hiring juniors, expect something different, then in vain – they won’t be able to do anything differently, because they don’t yet know how to think differently.

Problems of Shiva in the modern world

Different testers grow in different ways. But if you closely observe this slow process, you will notice that people who automate their work are more successful. Simply because it is impossible to digest the flow of tasks that falls on an ordinary technician every day in the modern world. There is a second way – to gain a foothold in the positions you have already achieved and tackle tasks that do not fit into you. And this is a sign of a person who, on the one hand, knows his desires, and on the other, his possibilities.

But what if you want to grow further? Do you need to take on more tasks than you can handle? After some time, there comes a fork in this branch – some people burn out and take a break (or leave the profession / change jobs and follow the path of a limited number of tasks – underline what is necessary). And a small percentage of the remaining ones automate the work around them. And they manage to do everything that falls into them, like Shiva, who has more than one pair of hands.

Here it is worth dwelling on what automation is, with which this block was started. Essentially, when a process is automated, the performer shifts his tasks onto the shoulders of the machine. But machines are designed so stupidly that they cannot explain all the nuances. However, most people do too. But in order to explain to a machine how to work according to a certain process, a person must accurately represent this process. And yes, at this moment you can think about system architects, who also have the skill of a technologist.

So we see that automation is not the most valuable thing in our history. This is the outer shell, manifestation, symptom. And the most important thing is the ability to understand the order of actions, provide all the corner cases and describe it in the form of accessible instructions, i.e. in fact create a process. And then it doesn’t matter who will do it – a machine, an AI, or a crowd of little evil gremlins. The main thing is that the instructions, input into the process and the result of this process are already there.

Management through the lens of skills

Management is a very abstract concept that consists of a huge number of skills. And there are a dime a dozen types of managers. We’ll return to skills later, but it’s a fact that management is practically the only growth option for a person in modern reality. Of course, only if he wants more for himself, and has not followed the path – I have enough work, I do what I do well, I don’t need more tasks.

Now the question is: how many super-expert level testers do you know who solve problems for entire companies? What about the developers who create new algorithms? The list can be continued endlessly, but the reality is that first you are a junior-middle senior, and then you are either a lead or a leading specialist. A lead is usually the leader of a group, and this is the majority. And the group leader is already a manager. And the funny thing is that an employee who has moved from the state of senior tester to the state of group leader usually has no idea that he is now a manager. Often, he also does not understand what management is in general and what his skill set is.

Such leaders have to master the necessary managerial skills in a very short time. And if you can try to put people management on parallel tracks from real life and quickly pull it up, then with processes everything is more complicated. And here the race is usually won by those who have optimized their work well while still being a specialist, and not a manager. Because, to my great regret, in management you manage resources and processes, not people. And if the skill of building and managing processes has been improved previously, it will be easier to master and grow further.

Archeology of processes, or where to dig up information about them

We already mentioned Henry Ford at the very beginning of this article. And for good reason, since people were building processes long before IT. In general, all of our IT is a new look at old things: processes, automation, advertising, marketing. This has happened before and will happen in the future. Only the tools have changed.

The most interesting and most difficult source to master is military history. And not the battles themselves, but the maintenance of the armies. There is a lot of literature about this; you can select the period you are interested in and look for patterns and analyze the details. This will give much more of what is now written about in smart books – a sense of processes. For example, Sun Tzu’s Art of War, which has to be read and applied very carefully due to the specificity of Chinese allegories.

A simpler option would be books about production. There aren't many books that go into detail about production, but you can start with Ford's autobiography or a book about the Toyota production system by Taichi Ohno. They are quite easy, but there is an opportunity to trace the relationship – why exactly did these masters do this, how did they find their optimization, what starting points did they have so that we would end up with this entire mass market?

It would also be a good idea to watch popular programs about production processes. You can start with “How it works” or create a social media feed of video recommendations about various large metal things that bend, cut, and that’s all. This is useful. But it’s even more useful to try to do such a process yourself in the area you like – it’s easier to stay motivated. This could be anything from harvesting cucumbers in the shape of a rectangular parallelipiped to small-scale production of aircraft models from thin plywood. It is important that you have in your head the practice of creating a set of operations, resources, and results.

Once you figure it out, it will become much easier to transfer your work to make money into these operations. And, as a result, it is easier to cope with it, take on more tasks and grow faster, which, in fact, is what all achievers want.

What does coding have in common with processes?

It would be strange to ask why a developer should learn to code. After all, this is his direct specialty. But it’s more interesting with testers – why do they need to know how to code? You can tailor the answer to the condition – to write autotests. This is what most testers will answer at the current stage of development of the field.

But it is important that autotests are the automation of your own routine. After all, if the tests are great, then it doesn’t matter whether they are performed manually or automatically. The question here is rather different: when testing manually, testers usually shift testing to the exploratory side. And success cannot be achieved there without a systematic approach to analyzing functionality, determining the necessary and sufficient volume of tests, regularly rechecking their effectiveness, and so on. To design such tests, you need a certain mindset with systems thinking. And to get such tests every time, you need the skill of creating a process.

Programming helps testers think systematically, because the machine needs to somehow explain its wishes. You can’t tell her: “here’s a feature, here’s a proof – test it and bring the result tomorrow” – she won’t understand. You have to translate your tests into a set of instructions. In the process, it turns out that a tester cannot penetrate everywhere with automated tests. He has to go negotiate with the developers about the necessary endpoints. And for the following features too. At some point, an understanding emerges of what needs to be agreed upon and how to build a feature release process. For example, developers write a feature, testers look at it in advance and report what endpoints it should have. Without this, the feature does not go into testing. This is how the process is built, which began with the fact that the tester decided to learn to program.

And this chain does not end with testers. The question remains, why should a manager learn to code? Here, too, the answer is obvious: some companies even test product managers’ hard skills in programming, and not just in management theory. But the deep essence remains the same as for testers: you need to better understand production processes, being able to decompose them into algorithms, and then design them taking into account resources and implement them in practice.

Now we can return to developers, who, on the one hand, master new languages ​​and tools, but do not learn anything fundamentally new: many convenient modern tools often do the work for developers – you just need to know which methods to call. Then you can do your work easily and naturally. But going beyond the boundaries of this approach leads to the study of architecture and approaches to organizing work with data streams. And these are the production processes of processing incoming resources and turning them into a finished product or blank for the next stage.

It turns out that coding is the skill of explaining to a machine what it will need to do regularly with data, what corner cases may arise, what to do in these corner cases, and so on. This is extremely reminiscent of the situation with building processes. Only in this case you have to explain to people, and this is often more difficult and interesting.

What’s most interesting is that here you can also practice building processes on your own projects. For example, create the most convenient bike tracker for yourself or write a game for friends. All this also involves analyzing the task into input data, processing and results, and in a large number of different planes.

Human factor or unknown variable in the form of people

In the last section, we drew an analogy between processes and algorithms. But the machine always executes the same commands in the same way, and will not say that this time the cat got sick or a burnout occurred, and everything lost its meaning. But people can.

Therefore, we also have to take into account the fact that the process in which people participate is unstable in itself.

Firstly, if there are many performers, stray light may occur. This is, for example, when a specific stage of the process begins to be performed a little differently. Or the task itself at one of the production stages begins to be interpreted a little differently.

In small doses with a large number of performers, such emissions are usually not dangerous. But sometimes mass infections occur when one performer convinces another that this small change is more correct. The second will convince the third, the third will convince the fourth. And now all the performers are already doing it differently. Then another mutation may occur, removing the entire process or a separate part of it from the original plan. And so, gradually, the process may become unbalanced, because the local performers know what is best.

Those who are trying to master the creation of processes with the participation of people can transfer their experience from real life: for example, try to explain to a child in simple language the goals of the process, talk about incoming data and relationships. And in such a way that he would not have the opportunity to interpret what was said differently.

If there are very few performers, you can get highly specialized employees who will have no one to replace them. And then in this situation, experience all the delights of people management and the loss of a key performer from the process for any of an endless number of reasons.

One could consider the process to be in a conditionally stable equilibrium with a gradual transition to a state of imbalance, i.e. with time to respond. But in a number of situations such time may not exist. Therefore, it is better to conduct an examination in advance and provide an additional strength circuit for the process. And even if one person gets sick and the second is on vacation, there will be a third in reserve who, although not perfect, knows how the necessary part of the process works and will be able to pick it up.

These examples are very specific, but in life everything is often more complicated. In practice, there are a lot of combinations of the human factor – from the next epidemic to the deliberate sabotage of an unappreciated performer. And such cases need to be learned to be provided for at the process design stage, laying down certain levels of stability and strength of the processes.

Conclusions: how to master skill nutrients

You can learn all of the above. To do this, they either change projects every six months, which is normal at the June stage, especially in outsourcing/outstaffing. Or they change companies or teams every couple of years. This gives a big boost to growth due to the fact that processes begin to pump.

But the processes always come up against hard skills, otherwise it is impossible to upgrade them. For example, I went to study to become a data scientist because I couldn’t build a process around neurons without fully understanding how they work. I’m good with processes, but bad with neurons.

But this is not enough: the human factor must always be taken into account, because neurons can provide data, but people will still misinterpret it. Therefore, we need to make sure that people cannot do this by automating everything as much as possible.

End! Learn the processes yourself, teach others, and you will be happy!