Category: Bez kategorii

Salary formula

This post was inspired by Management 3.0 and a very nice reading about Buffer’s policy.

Salaries are classified

Employees’ compensation is a very sensitive topic. In most organisations it’s also the most secret and the least openly discussed one.

My experience says that people don’t necessarily need to know the salaries of their colleagues, but they definitely want to know the rules that determine their wages. Regrettably, only a few organisations have an established set of clear rules and processes for calculating employees’ salaries. In most companies it’s delegated to HR departments that come up with a complex structure of pay grades and pay ranges, but the rules governing climbing the career/salary ladder is usually still very fuzzy.

The truth is that the main reason why so many companies are reluctant to make employees’ salaries transparent is the fact that it would immediately reveal how unfair current compensation system is and that many people are basically screwed. Counter to this, research confirms that long-term pay secrecy only hurts a company’s culture and results in negative morale, decreased performance, and higher turnover.

Transparency is motivating

Studies show that money is rarely a good motivator (my experience shows that it works only short-term or when somebody earns way below the market). On the other hand, money acts as a demotivator when an employee believes she isn’t treated fairly or she feels underpaid compared to her peers. And a lack of transparency makes it very difficult to influence people’s feelings and, as a result, have a company-wide perception of honesty.

A traditional approach to compensation requires employees to individually negotiate their salaries and pay raises with their managers which make this process prone to politics, short-term budgeting issues or current market demand peaks. It also favours smooth-tongued and social savvy people which doesn’t sound like a fair solution that should reward all employees for their efforts and contribution to the success of the organisation.

Salary formula

A solution to the problems discussed above is an introduction of a salary formula – an objective, incorruptible and reliable system for calculating employees’ salaries. A system in which everyone can calculate her salary (and a salary of her colleagues) and everyone knows what to do to earn more. A salary formula that everyone understands is a great step towards a compensation plan that pays people fairly for the value they create in the organisation.

It has to be pointed out that there is no simple remedy to how exactly your salary formula should look like and it’s something you need to experiment with. Above all, you need to make sure that it’s transparent and easy to adapt in a number of further iterations. And of course, before introducing a brand new salary formula, it makes sense to compare the resulting financial projections with your budgets and other internal constraints.

A good salary formula should take into account several variables, including:

  • role (job category – please aim at having as few as possible)
  • job level (maturity/seniority at a given role)
  • loyalty (employment time)
  • total experience
  • relevant education
  • location (very important for geographically-spread companies; costs of living and job markets are different in different locations)

An example of a salary formula can be found in this Buffer’s blog post.

Don’t include performance metrics

It may look very tempting to include some performance metrics in the salary formula, but it should be avoided. Most certainly it will lead to dysfunctional behaviours and employees trying to game the system instead of doing actual work. A salary formula is about steady, predictable monthly income, and compensation for employees’ contribution to the organisation should be resolved in a different way.

My thoughts

Personally, I like the idea of a salary formula. I’ve never worked in a company in which salaries weren’t secret, but I think that having some transparent rules around how employees’ compensation is calculated would definitely help.

However, I also understand that applying a salary formula is much easier in a young, small company rather than an organisation that hires 50k+ people around the world and that was successful in what they’re doing before I was even born.

Nevertheless, even if you’re not allowed to implement a salary formula for the whole company, in my opinion, it makes sense to give it a try at team or department level. At the beginning, you can use it as an advisory tool for checking salaries when calculating your annual pay raises or hiring new team members. And if it works well you can do another step and share it with your team(s) – I’m sure they will appreciate it.

 

Time-boxed sizing

Creating a long-term product-roadmap or release plan for a large project is a challenge. Features that are going to be implemented in many months ahead aren’t probably well-defined and, therefore, it’s very difficult to size and estimate them reasonably. Moreover, if you’re laying out an early version of the plan it doesn’t make any sense to invest significant time to scope and size those features because they are going to change anyway.

To cut this Gordian knot, you can approach sizing by constraining (time-boxing) rather than estimating.

The idea is to look at business value rather than details of requirements. The team, instead of sizing a feature in points, agrees with the Product Owner the amount of time (i.e. 50 days) he’s willing to invest in the feature bearing in mind its relative business value. This approach enables the team to reduce project’s uncertainty quickly and complete initial planning session at reasonable time and cost.

Of course, the ballpark provided as a result of time-boxed sizing is not set in stone and has to be revised on a regular basis (as each and every estimate, though). The more the team knows about the feature the easier it’s to split it into smaller chunks and finally estimate it in points.

It’s worth mentioning that time-boxed sizing doesn’t guarantee that the ballpark provided is correct and absolutely feasible. On the other hand, it’s not to say that time-boxed sizing is about guesstimating – the value should be reasonable. But for early planning exercises, it gives a common understanding of the size of the feature and brings stakeholders’ expectations into line. Adaptability and change lie in the heart of agility so it’s not a surprise that after several grooming sessions the ballpark size may change.

Time-boxed sizing was suggested by Jim Highsmith in Agile Project Management for large and lengthy projects. I think that it may be also useful in smaller projects when product management team is thinking about a new feature but doesn’t know how exactly it should work. Establishing a time-boxed size for such a feature sets clear boundaries and constraints for future discussions and makes the team plan within the ballpark. It’s not to say that the size of the feature can’t finally exceed an initial value – it’s Product Owner’s call after fall. But it forces the team to make decisions relatively quickly and allows them to focus on agreed ballparks.

 

 

Managing Product Adaptability

Overview

Creating reliable and adaptable software is not straightforward even if the team embraces Agile practices. In most cases, however, it’s not lack of technical capability or poor performance that prevents the team from achieving this goal. My experience says that the teams are aware that constant refactoring, automated tests, design spikes, etc. are required to keep the system reliable and adaptable – it’s senior stakeholders that usually fail to understand it.

Market is very demanding nowadays. Industry after industry demands for continuous innovation. Pressure for frequent releases and responsiveness to constant changes grows. And Agile seems a good solution for software teams to deliver valuable, high-quality products quickly. However, they need to be quick but should not cross the line and make mistakes. They “need to be quick but should not hurry“.

And unfortunately senior stakeholders far too often adds to this pressure and sacrifice long-term gain for short-term wins. Unreasonable deadlines are set and all the features are requested to be delivered. And in most cases the team manages to do that – velocity accelerates and the team delivers what they were asked for. But it’s a false acceleration, because corners are cut. And adaptability is the first thing that suffers from such an approach. Technical debt grows quickly and accumulates.

technical_debt_accelerated_velocity

Technical debt

Technical debt is invisible, especially at first sight and in short-term. Software is being delivered, features get implemented so why to bother about it at all, right? What really suffers, however, is system long-term reliability and, most of all, adaptability, but it usually doesn’t come to light quickly. But it’s a real problem that in long-term results in dropping velocity, increased cost and time to delivery, growing number of defects, and above all decreasing customer satisfaction. The company is no longer ready and able to deliver valuable software and adapt to tomorrow’s client needs.

technical_debt_coc

It’s especially frustrating from team’s perspective, because – if you ask them – chances are that they will directly mention parts of the code that need urgent refactoring and that contribute to technical debt the most.

Product Quality Assessment

This being said I suggest that one of the measures you can use to monitor if system’s adaptability is not deteriorating [too fast] is Product Quality Assessment performed by the team:

reliability_adaptability_assessment

This measure depicts team’s sense of the project’s “feel” (“smell” as called in XP). It can be supported by a chart that plots growth of the test code compared to executable code over iterations (both should be growing proportionally).

Why, in my opinion, this measurement is so important when there are dozens of other KPIs available? It’s not to say that it’s the most important KPI you should use, but it’s a canary in a coal mine that gives you an advanced warning of system adaptability potentially going down before other measures notice it. It gives you a chance to have a closer look into the problem before velocity drops, number of defects grows and the cost of getting rid of technical debt becomes [too] high.

Managing technical debt

Please be reminded that technical debt, like financial debt, has to be managed. It’s important to realise that there is no debt-free product, but you should be aiming at keeping technical debt low so that it doesn’t affect future product development. There are several possible ways of paying technical debt back, but the most important thing to remember is that it should be done regularly and incrementally. You need to avoid large balloon payments as a means of servicing technical debt when it’s far too costly, frustrating and time-consuming. By using some simple measures you can make technical debt visible – both to the business level and technical level. And hopefully convince everyone that technical quality is critical to achieve long-term goals and it shouldn’t be short-changed for current needs. Continuous value generation should be viewed from a whole product life cycle perspective after all.

To be fair, it has to be noticed that technical debt is not bad by definition – it just has to be acknowledged and managed properly. There are situations when technical debt doesn’t need to be paid back, i.e.: product nearing end of life, throwaway prototype or product built for short-life.

Please bear also in mind that technical debt can be intentional, i.e. when a fixed deadline has to be met. However, rather than being hidden it should be well-thought-out decision. The decision that not only allows for technical debt, but most of all acknowledges the consequences of introducing it and involves a concrete plan for getting it paid back in future. Otherwise it would be living a lie and asking for trouble.