Evaluation of Hourly Rates and Benefits in Software Engineering

Contents:
1. Introduction
2. Method
3. Results
4. Career Goals
5. Corporations

INTRODUCTION

How do we assign value to software engineering work?

From the perspective of software engineers the question is how to determine if a salary offer is worthwhile or how to set an hourly rate as a contractor. From the perspective of a corpration the question is how a particular candidates hourly rate fits within a pay structure given their background, expertise and expectations.

Software engineering is a complex, time-consuming activity. Entry level positions in software start with a baseline salaries determined by the type of software and industry. For example the staffing firm, Robert Half, conducts surveys of software engineer salaries based on type of work: 2018 Salary Guide for Technology

Big Data engineers ($212,000/yr) can make nearly twice as much as Front-End Web Developers ($122,000/yr). Security and Database Analysts are valued more highly than Technical Services. Additionally, years of experience heavily influences salaries with a 10-year professional able to command a 2-4x higher salary than entry level.

In this editorial I examine the high end of the spectrum, and in particular contracted work, where salaries vary from $150k up to $400k/year. As more experience is gained the number of factors involved in determining a salary become more complex. Initially perhaps only salary and benefits are important. As a professional career develops factors such as stock options, freedom to publish, contributions to open source, and flexible work schedule become increasingly important. I have witnessed many software professionals rotate through jobs in the tech industry attempting to optimize this balance.

METHOD

The following is one approach to setting or evaluating a professional software engineering rate. The data presented here are my own; tracked over several, real jobs in the field. My expertise resides in computer graphics, CAD/CAM and manufacturing software. However this approach may be applied to any career or candidate in a technical field. All wages here are discussed in terms of hourly rate as this allows us to compare salaries and contract work.

An important issue is that professional software engineers do not have one single rate. Other things being equal a job which offers benefits, flexible hours, remote working and stock options can invite candidates with lower rates than one which offers none of these things. Talented engineers might leaving a large corporation over a single factor, such as flexibility to choose project goals, since that may be essential to career growth. Evaluation of an hourly rate should be based on all of these factors.

Figure 1.

With that in mind, Figure 1 shows five different scenarios. In order to fully evaluate a position factors such as ownership of work, open source, publication opportunities, workload, teamwork, benefits and lifestyle are considered. Each factor is given a yes/no vote, whereas some maybe be given 2x weight if that factor is important. Honest evaluation is difficult. A software engineer might ask a corporation if they encourage publication in their field to which the answer might be “Yes, we value publication!”, but then either offer little time to pursue it, require elimination of technical details (the whole reason for publishing), or withdraw support at a later time. Therefore, in my own process as a consultant, I only write a ‘yes’ if the corporation agrees in writing (by contract) or shows signs that it is highly likely (e.g. if they are thinking about paper titles, asking about progress).

Figure 2.

With all factors tallied we measure a total positive count per job. Each ‘yes’ would indicate a benefit that could reduce an acceptable hourly rate, and each ‘no’ a drawback that might increase the rate. By plotting the Positive Factors vs. Hourly Rate we get a chart like the one in Figure 2.

RESULTS

The outcome is a rate trendline which corresponds to the acceptable criteria for a given professional. This rate trendline is an important metric because it can measure several things which a single hourly rate cannot. The data above represents real jobs in my own career. In this scenario I assume that Job A and Job B are stable points, either because I held them for a long period in the past (and therefore found it acceptable) or because it offers something essential. The hourly rate for jobs C, D and E are being evaluated.

Figure 3.

The trendline through Jobs A and B, shown in orange, represents my current career rate-criteria. I could consider any offer below this line unacceptable, and any above it beneficial. Conversely, as a corporation, if you conduct this study across many engineers with different backgrounds and expectations, you are getting a good deal from those below the trendline (or taking advantage of them depending on your perspective).

Consider an hourly rate of $120/hr for Job C (see Figure 1 & 2). While $120/hr might seem like a decent rate, this job offers 100% remote working and minimal workload, but does not support open source, does not encourage publication, does not all self-directed projects, does not have supporting coders (team hires), and does not offer stocks, benefits or tax withholding. All those factors place it on the far left in Figure 2, well below the rate trendline.

Look now at Job D. This position has the exact same negative criteria yet the hourly rate of $200/hr places it much closer to the rate trendline. This means that, given my rate-criteria choice (line), one would need to charge $200/hr in order for the negative criteria of Job D to be acceptable.

CAREER GOALS

What else can be determine with this technique?

Figure 4.

The most obvious aspect is that as ones’ career develops, the goal of the candidate is to increase the trendline overall. The implication is that, as experience grows, an engineer hopes to command a higher hourly rate (or salary) over their career.

Figure 5.

More interestingly, the angle of the rate-criteria line is a metric for how flexible or inflexible a given software engineer is to beneficial factor. If the curve is fairly flat, Figure 5a, it implies that hourly rate does not change much with respect to positive factors. Such a candidate does not care much about additional factors. This is usually more true with inexperienced software engineers as they gradually learn that such factors are essential to life happiness. Remote working, lifetyle and public recognition may become increasingly important to us as our careers mature. If the curve is fairly steep, Figure 5b, it implies that these factors are more important.

Figure 6.

Thus if one remains happy in a single ladder job with regular salary increases, then Figure 4 – steady upward increases – may be sufficient for most. However, dynamic candidates with greater career expectations in their field will observe their rate trendlines to rotate (or increase in slope), as their career matures and beneficial factors outweigh salary.

Note that the orientation, movement, slope and change of a rate-criteria trendline might vary considerably from one individual engineer to the next. Some might make slow progress in their careers (slow line movement), some may expect more external benefits as they grow (increasing line slope), others may work varied jobs (many outliers away from line), whereas others still might see less demand for their given skill-set (new jobs below the trendline). These scenarios depend more broadly on how ones’ individual career grows, what the market trends are, and how a given skill set matches job demand.

The question of which jobs or expectations are used to define the rate-criteria trendline is a personal one. In this example I’ve selected two jobs, A and B, to define my own criteria. One academic with lots of external benefits, and the other industry with fewer but good benefits. This is because I highly value career growth factors. As a software consultant this enables me to evaluate projects more easily.

However, I could have alternatively selected the top-paying jobs as my trendline. In this case I would choose jobs D and E (Figure 2), and this would say that money matters more to me than career factors.

Figure 7.

The long term goal of professional software engineers is to get a job in the top right corner — having all the career benefits and commanding a high salary. This also reveals the primary pathways to success. Path A) The most common approach is to have low career benefits, gradually increase our salary as we gain skills, and then expect more career benefits toward the end of our career. Path B) A moderate approach, useful for star candidates, is to increase both career benefits and salary as our career unfolds. This works for people who are in high need areas, or having desireable skills. Path C) The most difficult approach is to begin with career expectations and then ask increasingly higher rates over time. If one has specific values, or a particularly moral approach, this may be the course taken. Path C may be observed in academic careers where it may be difficult to improve salary to industry levels since the academic expectations of ownership of work, open source and publication are rarely supported by corporations. Unfortunately our universities are changing instead of corporations, offering fewer career benefits while maintaining lower salaries.

CORPORATIONS

Figure 8.

What are the goals from a corporate perspective? Of course the primary goal is to keep salaries and benefits low — they want to offer jobs below your trendline (undercut you). However, most businesses are aware that tight competition for software engineers requires them to offer competitive salaries. In other words, it is difficult to change your perception of $80/hr versus $120/hr. Therefore the most strategic corporate approach is to create confusion with respect to your career benefits. Why? The rate is fixed (y-axis), but, if the career benefits are flexible (x-axis), then it is possible to find a place below your trendline — thus undercutting you.

This practice can be observed all the time. When a business promises you can publish work in the future, or promises and then withdraws support for your project, they are creating confusion in your career benefits. Can you put a ‘yes’ under “publication encouraged”? Um, maybe.. When a corporation says they are seeking a team member to work with you, but then moves slowly in hiring, or redirects the hire to another project, can you put a ‘yes’ in the “team co-worker” criteria? Um, maybe.. The notion of RSUs, or Restricted Stock-Units, is by its very definition a form of fuzzy money. These are ‘granted’ to employees, but vest at a periodic rate. Thus a corporation can say that they’ve “given you” 5000 stocks but in fact those do not become available until they vest over many years. This approach works particular well for new entrants (graduates) not yet versed in corporate contracts. Can you put a ‘yes’ in the “Stocks” criteria? Um, sort of.. Most interaction with technical or product managers rely on the corporation creating confusion in your positive benefits. These are all mechanisms by which corporations can increase their own value without changing your salary.

The value of tech talent is increasing globally. If the supply of new graduates is unable to keep up with demand – as trends currently show – then these issues will become increasingly poignant. Corporations under pressure may either intentionally or casually create a culture in which uncertainty is favored thereby enabling supplemental benefits which are increasingly ambiguous or vacuous. The novice engineer, new to the market, will struggle with these issues at first as they gradually gain confidence and find their own career path. The professional engineer will find themselves increasingly aware of the importance of career benefits. Many frustrations will be shared among co-workers over managers, marketing and business areas not meeting verbal promises.

I have offered an Evaluation of Hourly Rates in Software Engineering. This approach helps to make transparent the relationship between software engineers and corporations; in particular the trade-offs between positive benefits and salaries as an evolving trendline. Economically, this analysis can be used to understand the pathway of a software engineering career and also the competitive behaviors of corporations.

Citation of this work:
2019. Hoetzlein, R. Evaluation of Hourly Rates and Benefits in Software Engineering. http://ramakarl.com

keywords: evaluation hourly rate rates engineer salary per hour price guide typical consultant fair freelance jobs salaries cost hire paid reasonable expert global fixed flexible