Don't get stuck at the same salary!

If you are not getting the pay rises you want, this article is for you. It offers a solution. One that most people who read this article will not be happy to hear but I hope will realise is correct.

The Problem

 It is happening. There is now a generation of software engineers in Poland that are finding it hard to get pay rises. The reasons are complex (another article?) but the data says that the average pay rise in our sector last year was 3% in Poland – very close to the 2.9% national inflation. It seems our market has matured. It is standard in countries like England for annual pay rises to be in-line with inflation - something that has not been true in our sector in Poland before. 

Coping but not Solving

So how have engineers here been coping and increasing their salaries so far?

• Swap to B2B and take advantage of 19% tax (for now)
• Change jobs more often to take advantage of high demand but low supply in the past few years
• Threaten to leave (hard negotiations)
• Work remote for a foreign company

The problem with all these strategies is they are limited, even one off, use. Keep changing jobs and you will become unemployable. You can only change to B2B once (and besides with the moves throughout Europe against contractors, this is becoming more risky). Threatening to leave will work once, exceptionally twice but it is not a card to play lightly. Working remotely for a foreign company is a one-time move.

These only buy time – they do not stop the inevitable.

One strategy guarantees a long-term high market value for your technology skills, which is obvious to engineers in Western Countries and, for historical reasons, is not so obvious in Poland. 

The Solution

Look at the graph below. It depicts three people, one at the beginning of their career as a programmer, the second in the middle and the last who has risen to be a CTO. Obviously, the CTO earns (a lot) more than the tech lead, who earns more than the junior. The bars represent what percentage of their daily work is producing code (coding, debugging, integrating, testing etc.) and what percentage of the day they spend communicating (meetings, reporting, mentoring, writing papers, attending conferences, presenting, dealing with customers etc.).

Obviously most of the juniors time is spent producing code. However, they spend some of their time in SCRUM meetings, taking instructions, listening to their mentor and so forth.

The senior tech lead spends half their time producing code but also spends half their time dealing with customers, leading the team, writing some designs, reporting to management, mentoring younger colleagues, answering tech questions from around the company, helping with recruitment and so forth.

The CTO spends 90% of their time communicating with others about technology. The CTO writes papers, presents to partners and customers, plans and communicates company tech strategy, mentors tech leads, socialises with other CTOs and company leaders, gives interviews and so on. If she is lucky, she may also produce some code.

This is a simplified career path of course and there are other stages in-between but the point is clear. As a technical person’s career advances, they must spend more time communicating about technology, and less time producing that technology. Defining ourselves as developers or programmers, specialising in improving our code production (language skills, coding skills) is limiting. We must focus on developing our communication skills as well.

This is not an easy message to swallow. Why? Two factors from Polish history definitely do not help.

History

Two unique factors have affected the attitude of Polish Software Engineers to what they see as their role. Why we (can I say we yet after 17 years?) limit our vision of the software engineer to those people who produce code.

The first is that for the last twenty years new companies opening in Poland did so (mainly) to cut costs. The talent here was developing quickly and provided a really great cost:value ratio for foreign firms investing in Poland. They came in with their management, their senior teams in place and wanted Polish Engineers to be chickens in a software factory, laying eggs as cheaply and quickly as possible. That situation has changed of course but the effect remains – Polish engineers were rewarded, for many years, only for writing, debugging and testing code.  It created a country full of engineers who believed that the best thing they could do to get pay rises was to be the best programmer in the team and doing anything else simply wasted time – things like writing papers, mentoring, documenting, travelling etc.

The second historical factor is the fact of communist rule in Poland. The shadow of the days of communist rule in Poland, left Polish people with an attitude of separation between them and ‘the management’. Engineers stuck together, and did not talk to management. Engineers delivered code, the rest was done by management. Engineers saw management (often from another country) as separate and not to be trusted or at least to be kept at a safe distance. The result was very little understanding of the higher concerns of the software industry in Poland and the specifics of the business of their company. There was a lack of development of communication skills and a retreat into the image of a developer as that and only that, which led to ‘that’s not my job’ syndrome.

Hill Climbing Optimisation

In numerical analysis, hill climbing is a mathematical optimization technique that belongs to the family of local search. It is an iterative approach of small steps of improvement. It finds local maxima but not global maxima. If we draw an analogy here, optimising your programming skills is a hill climbing approach that gets you the best local maxima as quickly as possible. Then you find yourself stuck. The hill does not go any higher. Instead you need to globally optimise and include both programming and communication skills to find the real global maxima.

At Consult Red we often struggle with this phenomenon when recruiting. We search for people who can do both and when we find them, we do not expect them to be cheap. However, what use is a great engineer who cannot communicate an idea? 

Author

Chris Thornborrow is a pseudo-foreigner who came to Poland nearly 20 years ago. Chris readily took to communicating as a younger engineer and he has been in management of some kind, in England and Poland, for 25 years. Chris has been here long enough to know that the one constant of life in Poland is change and maintains that it is time Polish software engineers concentrated on communication, not just coding.