M-Motivation

The post is the author's personal opinion and does not represent the opinion of the company. All references are not real and conclusions are hypothetical. And do not take other people's thoughts too seriously, because the question is, to put it mildly, emotionally complicated.

As you understood from the introduction, it's going to be hot.

You have colleagues who leave work at night and come to the office in the morning before you, they are available 24/7, ready to spend weekends and holidays at work without pay, are always in touch, and seem to be a bit fanatical. They are put as an example by managers and you sometimes feel uncomfortable that you are not like them — that you do not spend all weekend learning another technology, or launch the service in the production, or do not respond to customer emails on weekends. Wake them up at night, say two words about the problem, and you will be told exactly where the problem is and how to solve it. They are writing the code at home all the time, refactoring something, and living by the project. I bet everybody has such a colleague or friend. For me it remains unclear: Why would they even do that? What is their motivation?

I have been thinking about possible motivations for myself and what kind of motivation people may have at all. So, let's go right into it.

The first stage of motivation, which is usually typical for junior developers — is a desire to have a roof over the head and some chips not to starve to death. This is the so-called basic motivation if it does not exist, it makes no sense to do anything at all. People at this level usually are motivated by the fear of being fired, otherwise, they will have nothing to eat. This motivation is so overwhelming that a surplus of it is also usually spent on extra work as these people want to quickly move to the next level of motivation.

It's not a special feature of this level but it is connected with...

Of course, there are different reasons to work — ambitions, education, relocation... There is nothing wrong with them, everyone has their goals. But I am sure of one thing — money is perfectly converted into any of the potential desires that I have or will have. That is why I consider "grab as much money as possible" as the default life goal. And then I can start doing serious business, without having empty pockets.

In my opinion, the IT field still cultivates the image of a geek who wants to solve complex problems for free. But we are all interested in money, even if "it is not appropriate". Software engineering pays well, I think everyone understands that. Companies make good profits and don't hesitate to share it with the staff — the more the industry earns, the higher the average salary. I am convinced that it is ok to get good money for good work and not to be ashamed of that.

But, salary is essentially a motivation for coming to work, nothing more. We all know that coming to work and working — things, although related, but not equivalent, and companies usually want the work to be done and done well.

Doing work is not about productivity but efficiency, especially in IT. So, a proper way to increase the salary is to reduce work time. Stop counting your income per month, not to mention a year. The right question is, "How much do I earn per hour?" Constantly recalculate and refine this only valid indicator, be pragmatic. If you spend eight hours working but open your laptop at home to "check something out," you are not working eight hours. As long as the work laptop is open outside the office, you are giving your time to the company for free.

I am not saying that it is time to stop your work right after 6 o'clock and go home if you have a bug in production. I am just trying to clarify things a little bit so that you as a developer and as a manager could make conscious decisions for yourself or for your fellow engineers. It cannot be excessive to calculate your own time as it is one of the most valuable things in your life. Vision will not recover, the spine will not straighten, and the time lost in learning a new buzzword will not come back. We don't have much time for all sorts of events. A good around-the-world trip takes a year — that is if a person has lived on average for 80 years, at best he can do it 80 times. If you read all day from sunset to dawn, then perhaps you can cope with 1 book of decent size per day. In a year it will be possible to read 365 books if you do nothing else. You get the point — there are obvious limits. I guess, I read less for the same reasons.

A tiny bit of truth. So, the paycheck is for a well-done job — you do a decent job — you get the money. Makes sense so far, doesn't it? That's what the perfect relationship between the company and hired employees looks like. And now a little surprise(at least for me it was) — if you agree with this model, you should understand that it directly follows the fact that you cannot ask for a salary increase for doing your job. That is the reality.

Move on to the next level. Here the developer is already a little relaxed — starvation is no longer a threat. The developer is more motivated not by internal goals and desires, but rather by the prospect of receiving external encouragement and awards. And the managers are successfully using that.

If you have never heard of the 10x engineer myth, it is a great concept. It comes down to the idea that an engineer can be 10 times more effective than an "average" engineer. Cool, right?

The business came up with this handy incubator. The developer should take more responsibility and solve all possible problems. Then he becomes a team lead, and later moves on to managers because that's what the 10x engineer looks like. Here is an example to illustrate the concept, give 10 engineers a manager and he will make each engineer a 2x engineer. The math here is simple — the manager will be a 10x engineer in this example, moving the Jira tickets, pushing everyone on the daily standups, and removing unnecessary unit tests to make it to the demo. The developer in turn is ready to fuck years of technical expertise so that there will be one more bad manager in the world and one good developer less. Everybody knows if you want more money — either move the Jira tickets or rotate the red-black trees on the whiteboard.

The task of a typical manager at any level is to do the project(s) quickly, and cheaply, and keep the team from running away. So any typical manager will always go through the following stages if the developer copes with the current workload:

1. Brainwash them regularly to point out how great the company is, how big their mission is, and how important the engineer's contribution is. The figures on their paychecks will seem far less important than the multi-billion dollar market the company is trying to dominate.

2. Give some small benefits to developers. It is a great way to provide employees with added value at a low cost and efficiency. On the one hand, such things are not taxed, as the salary is raised, so the employee will get more value for the same money.

3. Give the goal — the next title of Super Hyper Cool Software Engineering Overlord III Tier

The developer level really depends on where and with whom he is in the company, the people, and the content he surrounds himself with. Perhaps, among junior devs, he may look like a senior. If he has worked for a long time in the same company, his level can be determined by years of work, not his real skills. Many positions, unfortunately(or is it?) are given based on seniority rather than the ability to create and solve problems.

The concept of levels is subjective because the person who evaluates may also possess false beliefs about these levels or be a fictitious senior, whose true depth and breadth of knowledge are quite questionable. Please, do not accuse such people of narrow-mindedness. Perhaps their daily work cannot create the conditions for growth. It happens too. And it happens much more often than you think.

4. Give the developer a little more money so he doesn't run away.

After those steps, the developer on average feels as if he was noticed that he is super cool, that he goes in the right direction and continues to take the bullets. This dedication seems like an investment in the future for a developer but it is an unnecessary gift to a company(I hope it is conscious at least).

And if after a continuous effort, the developer does not get a reward, he finds the problem in himself and starts to do twice as much. Then there is burnout and possibly insanity.

The truth is that you can work your ass off, optimize every line of code, get tired at meetings, bury yourself in emails, and get a pat on the shoulder. Initiative developers don't get 10 times as much money. Besides, unfortunately, it is always difficult to understand the contribution of each individual developer to the final product.

Managers encourage developers to have a competitive way of thinking in developers. There is a hierarchy of levels inside the company, there are incentives if you volunteer at a company event, or John has completed 50 courses and knows all the basic buzzwords, or Ryan presents a company at the conference, and so on.

How not to lose your position in this rating?

Do nothing. Forget the fuck about it. Even if they pay a bonus for winning a contest, we take it and use our indicator — count it in dollars per hour.

All this is quite primitive and quite effective because on average developers are still very childish no matter how old they are. After some time doing all those activities, you will be saying "That was a nice experience" and thinking "Why the fuck did I agree on that bullshit?".

In the development of an intellectual product, previous motivations work badly. Instead, this one works well — "I work because I like what I'm doing". Motivation 3.0 is not related to external awards and incentives but to internal satisfaction from the activity itself.

We need happy developers because happy developers make the best code. This is not a speculative conclusion, but the results of scientific research by scientists from the University of Stuttgart, the University of Helsinki, and the Free University of Bozen-Bolzano.

The necessary conditions for Motivation 3.0 to work(my representation):

Software Engineering is one of those jobs that is designed to make other people's jobs easier and more automated. If the value of the task for the business plays a role in external motivation factors, then you can get internal motivation from understanding what kind of help you provide to a particular person — the end-user of the final product. This awareness of yourself as a creator and not as a Jira ticket mover is inspiring. This is how I feel as a developer.

But this attitude of being proactive, and being creative is often broken by the external circumstances in which a person finds himself, making him obedient and loving routine. People need the autonomy to choose what to do, when, with whom, and how. Everyone wants to express themselves and have a certain degree of freedom in their actions. For developers it may be formal free time to work on pet projects, or to learn things that are not directly related to their daily work; flexible working hours; contributions to the design of the final solutions and products, not just their implementation. When the work is not in the spirit of "do as I said", but "Look here's the data, let's discuss how to do the task in the best way" — there is a huge difference.

But autonomy is a double-edged sword. Usually, only qualified people know what to do with it. But they are the ones who need it.

And also there are people who overuse this autonomy, usually more senior guys who want to do everything only with their own hands and sometimes on weekends. It is both good and bad for the team — the good thing is that they're likely to do everything properly and consistently, while the bad thing is that the team may find unpleasant surprises like a brand new or refactored code after the weekends, usually not covered by tests and usually, there are missing details that fuck up everything. Those guys think they can't go on vacation or get sick because their team will do everything wrong. They have great technical expertise, but they overestimate their own importance. And they can get sick, and take a vacation, and even quit. In a couple of days, the team will start working quietly, without surprises, in a week or two the team will close the sprint and remember how they used to plan and evaluate the tasks. In a month there will be experts in the team — those who understand parts of the system well. In two months, they will only be remembered at beer parties. This is life.

Motivation 2.0 requires obedience and discipline, and motivation 3.0 appeals to participation and interest. Only interest and passion can lead to mastery. Skill is related to the flow when the task is fully consistent with our abilities.

Developers are eager to become better and need the help of the management to achieve their growth. One of the proven ways is through tasks that are not very easy to cause boredom and lower motivation, but also not too difficult to raise anxiety and probably lower performance. On this axis, the developer also wants to feel that the focus is not only on quantity but also on the quality of work, as this will allow them to show more skill and learn.

Everyone needs a purpose, an idea of the final goal of what he or she is doing. If people come to work just for the sake of money, it is unlikely that the best professionals will work there, and to attract employees, the company will have to raise their salaries above the market average. But when there is a clear goal, a problem that needs to be solved then the developer has motivation from understanding the goal of the project or the goal of the end product. The goal doesn't have to save lives — it doesn't matter if the goal is to make software for planes or an online player for PornHub — there has to be a goal.

But when a developer understands that he is been given tasks to just do something, to occupy his working day — the negative effect of meaningless work can be very heavy even after interesting tasks appear.

This sense of correctness is just a hygienic factor. Developers like doing what is right and don't like doing what is wrong. When you are offered a dream job, where developers write unit tests, have working CI/CD pipelines, have a transparent process, where you can be happy and get, say, 5x salary, and a job where everything is terrible, but you qualify and you will get 6x salary, probably the choice will still be in favor of the first.

I like working with smart guys around. I want to work and get in touch with smart people. And it's not that I want to grow up professionally somehow by using them, it's that there's a different level of communication, understanding of the context, the overall level of conversation. It's exciting, it's motivating, at least for me.

Into the environment, as I called it, I also include the hierarchy of management. In any company, there is a structural hierarchy in which some people are making decisions and some do not, someone is a boss and someone is a subordinate. In small companies, it's usually less official, but it still exists.

In essence, it is a division of responsibility and it is absolutely necessary. This hierarchy in itself can put pressure, on the dress code and force courtesy to the peculiarities of meetings and agreements. Also, there are two elements the developer and I think any other employee distinguish:

• his direct supervisor, the one he directly reports to;
• top management is the one above his supervisor.

A developer most of the time will be loyal to his manager if he is trusted, respected, and all that, not the company.

The developer wants to feel that the company appreciates, trusts, and cares for him, and the manager's task is to convince the developer of this. Frequent talks in private, confrontation with top management to protect the interests of the team, giving advice to developers on their career path, and creation of a good working environment — this is what a manager should do.

In many cases, the employee's wishes go against the wishes of the company, so being a good manager is a difficult job, you have to compromise. Managers who are not able to develop a sense of loyalty to themselves will face the staff rotation in the department.

I'm sure a lot of people will find in this article a hatred of companies or management or jokes about geeks. But I didn't put that into it. I tried to explain the rules of the game in IT, both for managers and developers. I tried to explain what can drive people and how this motivation can be understood or guided so that everyone wins because in any case, we're all in the same boat.

Believing in people is hard, delegating is hard, but micromanaging is nice and easy. Managers' task is to make sure that the team makes a product, that the team members grow professionally, that the team has the conditions for work, and that everyone achieves their goals. And that's when the manager starts doing his job, that's when he gets rewards and bonuses from bosses.

The reward takes many different forms. Money, social status, and other people's approval are the most obvious forms of reward. The reward for work confirms that we have correctly analyzed the costs and benefits. Reward gives you confidence that you are moving towards your goal. While this is still the main motivation to go to work, it does not make developers happy in the true sense of the word.

I like the way to think about myself as the CEO of a company named "I". I make important strategic decisions, I increase my profits, and my sphere of influence, and I achieve my career goals. All this becomes immediately clearer and on a higher level if you think of yourself as a company in which you invest your time and energy. Think about it.

Everyone has their work to do, everyone has their motivation, you, dear reader, just have to find your own — the goal that is yours and is not imposed by others, maybe you should start being a dick.

Additional materials

• Drive: The Surprising Truth About What Motivates Us
• Subtle Art of Not Giving a Fuck