Whose salary rises faster

During recent few years we can observe significant salary growth trend in most cities in Eastern Europe. The rates go high for all qualification levels, but does the speed differ for different levels?

The following graph is the result of some extra investigation, that was triggered by the comment to one of my previous posts (IT salaries in Eastern Europe). It shows the proportion between salary weights for:

• beginner - entry level technician(0 years of experience);
• specialist - intermediate level (1-2 years of experience in particular area);
• professional - advanced level (3-4 years of experience in particular area);
• expert - a professional with 5 or more years of experience in particular area.

Before I'd processed historical salary information, I was sure that Juniors' salaries rise faster, and I had some explanation that seemed very reasonable to me:

• beginners have more areas to improve their personal qualification level. It's quite easy to move from nothing to the next stage in their professional career;
• junior's salary is usually much lower than an employer can afford. It means that it's not a problem for a company to keep her/his salary rising constantly thus increasing the person's loyalty;
• intermediate level professionals are most demanded on the market because they already have enough skills to participate in production process, and their salary still allows to be profitable.

But the figures show a bit different result. The next image contains the salary growth curve for an average IT specialist. X axis lists years of experience, 6 means 6 years of experience in particular area by October 31, 2007. You can see two graphs, one of them uses only present salary information. Another one is based on historical data for an average developer who started his career in November, 2001. These values are adjusted by the coefficient of inflation.


One more chart displays proportion between salaries of 4 mentioned categories (beginner, specialist, professional, expert). The values are also adjusted by the coefficient of inflation, so it looks like salaries were not changing during the period between years 2004 and 2006. Actually the change was just enough to compensate the inflation:

As you can see, my classification identifies only 4 levels of qualification. What is the next point in a career? - is a regular questions for almost everyone in IT. Actually, what is? I'm going to return to this topic in one of future posts, and review several options as well as the difference between employee expectations in IT and in other industries.


These 3 charts can not be re-republished without written permission from Serge Stepantsov, this blog author. However, anyone can post a link to this page.

Project Success

Scott W. Ambler, a DDJ Senior Contributing Editor, Practice Leader Agile Development with IBM Rational, and author of several best-selling books conducted a research to find out how people define projects success, and provided some statistics to his reader (Defining Success. Dr.Dobb's Portal. October 31, 2007):

• Schedule: 61.3 percent of respondents said that it is more important to deliver a system when it is ready to be shipped than to deliver it on time.
• Scope: 87.3 percent said that meeting the actual needs of stakeholders is more important than building the system to specification.
• Money: 79.6 percent said that providing the best return on investment (ROI) is more important than delivering a system under budget.
• Quality: 87.3 percent said that delivering high quality is more important than delivering on time and on budget.
• Staff: 75.8 percent said that having a healthy, both mentally and physically, workplace is more important than delivering on time and on budget.

In general, I like his approach and ideas. However, there is one thing that bothers me a bit. Despite of the fact, that Scott provides different rankings for different categories of respondents, at least 94.7% (there is no exact information about others) of respondents were IT people.

Having tough experience working with various customers, and being a customer myself, I wasn't able to identify which one of the following is usually more important: Quality, Scope, Time or Money. Each case is different, but almost all the time it's some kind of a compromise between those four variables.


Everyone would be happy to get even more than they wanted and, in additional, in supreme quality. But in real life we still have to worry about time and budget, which are usually (yet, not alway) general constraints. So I agree that quality and scope can be ranked on the 1st two places... but only after taking other constraings into account.

Who should sell

Disclaimer: it's about IT outsourcing service.


There is a popular slogan: In our organization, everyone sells!

Actually, this principle was intended to motivate all employees to think about customer needs while performing their everyday work. However, sometimes management goes further, and tries to use this idea wider delegating selling responsibilities to production departments.

From one side, this is a very good initiative, and there are a lot of arguments in favour:

• production personnel is usually more technical, so they can quicker estimate the complexity of requirements, propose different possible solutions, involve the customer in discussion;
• production team understands the needs of existing customer better than sales people do, because of day-to-day interaction;
• having technical background, it's easier to answer process-related questions, thus presenting the company on more professional level.

These arguments are quite strong to start thinking about deep involvement of technical staff into sale activity, at least with existing customers. Why not?

Actually, why not? I still think it's not a bad idea. It just have another side of the coin:

• The most important task for a development department is production. This is the area where they have to provide measurable results. If the results are not satisfactory, even a good marketing deal won't be considered as an affordable excuse. So production managers postpone sale activities to the sideline, and usually its turn never happens.
• Size of a development department is usually the same or even smaller than amount of work that have to be performed. It means that these people simply have no enough time to do something special for sales.
  
• Production department personnel is usually not well trained for selling activities, and most of them are not disposed for this role.
  

Again, listed items do not mean that sale activity is only for sales people. They just have to be considered.


Even more, if we talk about marketing not about just selling process, then developers are often really involved in marketing whether they know it or not. If they are involved in deciding what features to build [and how it will work], they are doing marketing (And the Geeks Shall Market by Erik Sink. Business Of Software Blog. October 29, 2007).

Self-Motivation

It's quite usual to see newcomers being quickly recognized by management for some their achievements. The most noticeable category of rising stars is students, who has just started their professional career.

This fact is not surprising. People in the beginning of the career are usually very motivated to move to higher levels. These guys do a lot to provide quick visible results, follow all (well, about all) corporate policies, do not forget to provide all required reports and so on. They have a lot of things to learn, and a lot of stuff to do to demonstrate that they are not worse than others, they are better! It's a good stimulus, isn't it?

So are students usually more motivated than experienced professionals? May be, but I would say it in a different way.

Beginners are motivated by the need to prove their professional level and their ability to take different role or position. Some of them spends effort to be recognized by colleagues and management, others stay goals just for themselves. Both of these types can make a good career, but the first category usually does it faster and a bit chaotic while career path of the second group is more stable.

every soldier dreams of becoming a general;
every lieutenant dreams of becoming a colonel;
and every captain wants to be a major.

IT is quite similar. While gathering more knowledge and experience, the aspiration is being reduced.

Professional life becomes simpler, people just focus on their everyday activities. They do not try to do something perfectly and to get some bonus for that single achievement. For them, good results are not something uncommon, good results are normal.

Of course, professionals also do need to be recognized. Not just for some individual output, but for the constant success. They do not claim to get such recognition, but if such regular good work is being permanently ignored, the person starts thinking about her/his job in a different manner...

The Elite Team

In the early 1970s, a vice president of one of our client companies sent around a memo on the subject of travel expenses to everyone in his division. You may have received similar memos on the topic yourself, but this one was different. It said more or less this: "It
has come to my attention that some of you, when traveling on expenses, have been traveling economy class. This is not an economy-class organization. This is a first-class organization. When you fly on business from now on, you will fly first class." Of course that memo cost money. The expense was very real and the only thing you could balance against it was an enhanced sense of eliteness. At least one organization thought that was a valid tradeoff. Couldn't happen in a real-world corporation, you say? It happened at Xerox.

Peopleware: Productive Projects and Teams.
by Tom DeMarco, Timothy Lister

This is a very good sample of understanding the team spirit background. To feel and act as an elite team, its members must not just hear slogans propagandizing that they are the best. Each team member must know that they are allowed to be different, and really to be elite.

PR and hiring expectations

Today, I was told the opinion, that company public relations (PR) does not have any effect on the number of candidates "waiting in a line to be hired for the company". A background for this opinion was a statistics, that didn't reveal any hiring increase after massive PR campaigns.

This statement is probably correct... in a case when we are talking about large well-known company.

But if potential candidate never heard the company's name before, or heard the name but still has no associations with it, then chances are she/he won't pay enough attention to a vacancy. The ad can just look like a hundred other similar ads from companies, that will never give a lot of new opportunities, and that nay go out of business pretty soon.


I completely agree that PR doesn't help to hire a lot, but on the other hand its absence kills company growth.

Maintenance and Development... The difference?

"I do not want to work on a maintenance projects", - that's what can be heard from software developers and from candidates quite often. At the same time, most of them can't describe their understanding of the difference between project maintenance and project development or, in other words, the difference between the things they don't like and that they do like.


Project maintenance phase "description"

Below is the list of items that people use to describe the project maintenance phase:

1. Bug fixing
2. In few months after beginning of the project
3. When software architecture is ready
   
4. After the 1st public release
5. When you have to update other's code

So, every project, that is being developed for some time by two or more programmers and that has not failed yet, is a maintenance project, isn't it?


Why it happens

Actually, I was not satisfied with this simplified answer that every project is a maintenance stuff, so I tried to get more information about people, who insists that hates those maintenance projects. After collecting and comparing the results during a period of 4 years, I've come to the following classification:

• Husband is the developer, who works on some particular project from the very beginning, who came through a set of successful public releases, who knows about that product and its code everything. Such persons can be stuck to the project for quite long period of time and fill comfortable enough. However, one day can start "a middle age crisis". This can be a good push for "starting new life". After this point, Father hates even an idea to be involved in new long "engagement". Such crisis can be very short or long enough, but in most cases the person returns to its habits and becomes ready again for new "long relationship".
• Researcher always tries to improve something. He spends part of his work day performing planned activities, and other part looking for new information, trying different technologies. This person can be really bored by the project if it requires 100% of his time and doesn't allow experiments. A lot of people pretends to be researchers, however only very small percentage of them really are. Most projects are still OK for a researcher, because most projects are happy about introducing something that improves the result. Maintenance projects are even a land of plenty for research, because they usually do have some time for improvements. If it's not the case, then it's better to use the researcher on a different task.
• Grandma is a person who pretends to be bored spending a long period of time on similar tasks. However, such developer does nothing to change it. Such kind of a person continue using a rotary phone and hate it, but won't try a button one because "it's too complex" and she "doesn't know how".
• Pseudo-researcher is a middle between Researcher and Grandma. Such person isn't afraid of reading some new documentation, however she/he used to reject most innovations because "there is too late to integrate them into existing project". I'm sure that you heard a lot of times a phrase like: "Well, the idea/solution is really good, but it's impossible to use it on current projects because [...here some generic explanation, that fits all current company projects, goes...]. Let's utilize it for our next projects".
  
• Hack-worker is a programmer, who didn't use to do his job in workmanlike manner. Doesn't matter, if he joined the project from the beginning or when some parts had been ready. This person performs activities ignoring all circumstances, which are not directly covered by the task description. If he needs to paint a wall, he'll never be worried about keeping the floor clean. Fixing a bug, such person can create two or three new. After some period of time, when the number of project-related problems becomes quite high, hack-worker starts hating the project, and other "maintenance" projects. His favorite is to start the project and to leave it before bugs have been revealed.

What is it all about?

Good question... This analysis is one of few things that I had done before I realized how to use the results. So I was just collecting the statistics because I was interested in finding a real reason that stays behind hating "maintenance activities".

But one day, when I was involved in consulting activity related to hiring process in a company that had several software project of different kind, I returned to the same question and found out a way to use this info.

As a result, we prepared a set of questions which helped the company to classify job applicants in one of 6 ways^*, and then select appropriate project for particular candidate or do not make an offer at all.

--
^* 6 ways are 5 groups listed above + people who doesn't make too significant different between programming and "maintenance".

Formula for Success

While reading Eric Sink on the Business of Software, I've found a quote that very closely deals with one of my first posts in this blog, the one about mistakes and activities:

Would you like me to give you a formula for success? It's quite simple, really. Double your rate of failure. You are thinking of failure as the enemy of success. But it isn't as all. You can be discouraged by failure - or you can learn from it. So go ahead and make mistakes. Make all you can. Because, remember, that's where you will find success.

Thomas J. Watson, Sr., founder of IBM

If I had more time...

Sorry, this article is not intended for reading :-) It's just few notes that I want to keep for myself to return in a future (hm... am I really going to return to those topics one day?). It just like in the anecdote:

Sergeant: If your head is like a pan, and it's unable to keep anything, then get a notebook... or two as me...


So, If I had more time, I would write some interesting things about:

• Project Documentation - how to keep it actual all the time, and have people happy creating it;
• Side effect of standardization - the results of being paranoic about having everything standardized;
• Maintenance and Development. Where is the difference - by the way, where it is?
• HRs make IT salary grow in Eastern Europe (2004-2007, and may be it's still actual);
• The truth about offshore dedicated teams (companies|commands) - how these teams are being staffed, how vendors make profit, does customer have better options;

• If I had more time, I would... - how can I share time management knowledge, if I give such excuse myself? Well, I have a solution for myself, but I have some things to do that are more important for me in this short period of my life. It means, that one needs personal time management only if she/he has no enough time to complete the most important tasks.
  

Eastern Europe salaries in IT

The information below was collected from different sources in Belarus, Russia and Ukraine. However, please note that the graph below does not reflect trends for St.Petersburg and Moscow, because the statistics for those cities was significantly different in comparison with other places.




This chart can not be re-republished without written permission from Serge Stepantsov, this blog author. However, anyone can post a link to this page.

Comparison: Custom Solution vs. Standard Solution

Working on one task, I had a need to analyze the benefits of custom solution development against implementing particular standard platform.

Among other steps, I tried to do some web search to learn others' opinions, and to find out some related public materials. To my surprise, there were almost nothing published on this topic, except some marketing articles advertising their product or outsource development company. So, I've decided to publish summaries, that were collected during my analysis. Most of these materials are not related to the task I was working on and I didn't have a time to rewrite them in a better form yet (hope to do it one day), but please feel free to reuse ideas (e.g. comparison parameters) or to provide comment, which are always very welcome!

Note: in this article, Ready Solution means commercial product, not an open-source.

Attribute	Ready Solution	Custom Development
Base Product Cost		Usually, initial project investment isn’t required at all, or the amount is quite small.
Initial Customization	In most cases, ready solution requires less time to customize to a satisfactory level. However, rates for this customization are usually much higher than custom development rates.	Custom development always takes longer than implementation of existing solution. Yet, it’s still usual that Base Product Cost + Initial Customization cost for a ready solution is higher than total cost of own project.
Implementation Period	Implementation of some ready solution is always much quicker than custom development. If not, then it only means that bad product has been chosen
Licensing Fees		In a case of custom development, your usually have complete ownership over the source code, so there are no regular payments (except for some other 3rd party software, that can be required for application functionality)
Product Maintenance Cost		Custom solution is usually cheaper to maintain, because it’s possible to choose between different maintenance suppliers or even to maintain in-house. In a case of standard solution, a customer is tied to the original supplier and their exclusive rates.
Control over Product Evolution		The customer has exclusive rights to controls personal application evolution. However, if original supplier continues development of their standard product, they have a better source of information for new versions – the feedback from different users.
Product Versions	If a standard solution is being intensively developed by the supplier, it’s possible to benefit from new product versions that are being released. However, in most cases, it also means that the customer has to pay for features that they do not really need.
Knowledge Source	Usually, a standard platform already utilize some experience from the industry, so ready solution can become a good knowledge source in a product business area, if the customer has no very clear understanding for the future system.
User Training Cost		Usually, it’s easier/cheaper to train users for a custom solution, because such solutions are based on existing known company processes.
Technology Decisions		The customer has exclusive rights to select technologies that will be used for the solution. It allows to follow existing company standards (if any), or to select cheaper or better environment.
Risks	Utilizing existing solution usually has lower risk than trying to create a custom one. With a ready product it’s much more probable, the customer will receive working system on time and budget.