As software engineers, we do not realize it but we live and operate in a weird world, very different from that of our colleagues in sales or marketing or even our engineering colleagues say in manufacturing. We grapple with a level of uncertainty and chaos not found I would argue in any other part of the company. So much so that we have come up with processes like agile to help manage that chaos and so far, that seems to be working pretty well.
However the next challenge, and one that nobody seems to be talking about, is that an agile software team must live within a company with agile friendly processes. Not doing so dilutes the effectiveness of those often vital processes and also results in all sort of other tensions that are hard to diagnose. One example of an area that needs to change to embrace agile development, is performance management and compensation.
What is wrong with the current system?
Well, first of all, what is the current system? The current performance management cycle – setting commitments, doing reviews and so on runs on the HR clock or the annual clock. It happens twice a year, at the same time, across the company. Sales goals are set, manufacturing targets are set and so presumably the goals for software engineers should be set as well – right? Hmmm … not so simple. Software project start up at all times of the year. Some projects slip blocking resources for other projects thus delaying them. Other projects get cancelled – the software train is ready, when it is ready, if at all it ever leaves the station! This can make commitment setting really hard. Software engineers often hear their managers or HR say things like put in what you can and update it later.
Then, there is a lot of hand wringing about creating SMART commitments. To start off with most people cannot even say what the abbreviation SMART stands for. To make matters worse there are a multitude of definitions. Leaving all that aside, writing SMART commitments is not easy as it sounds. Software is notoriously hard to measure – you cannot commit to “Write X lines of code, with less than Y bugs in Z months”. That simply makes no sense. It also makes no sense to put in the specifics of what I am going to build because that changes through the life of the project sometimes drastically. So where does that leave you – a commitment that reads “I will fulfill all my sprint goals on time” – do you really have to put that in writing? That is what is expected!
So what ends up happening is that people make a best effort at putting in commitments and try and make those commitments as SMART as possible. In the mid year and annual discussions, people look at the commitments and realize they changed substantially. So the employee ends up writing what he really did and the manager puts in her comments on what actually happened, largely ignoring what was put in at the start!
In reality what happens through the year is that the manager and the employee or the employee with the scrum team figure out what needs to be done every two weeks and they just do it. Their inputs vary widely – they respond to new management initiatives, new market information, competitive threats, beta feedback, lessons learnt from the last sprint and more. Some things go well and others fail, for various reasons . However there is constant explicit and implicit feedback to the employee from their peers and their management chain and corrections are made. So commitments are set, actions are taken and reviews happen multiple times through the year – in the scrum tool chain and via hallway conversations. These are the commitments that really matter and they do not sit in the HR system.
So Why Do We Set Commitments?
Here are the reasons I can think of:
- Clear Expectation Setting: The idea is that if there are specific measurable (the S and M in SMart) commitments, then employees can be held accountable to deliver. However, as we saw, the specific measurable commitments are in scrum tools and seldom in the HR system or they quite often evolve in hallway conversations. Further in sound organizations, you expect people to deliver what the promised without having it in writing. If there are issues they are caught and fixed immediately without waiting for a 6 month performance review.
- Compensation: This is how an employee thinks this works – I set Specific Measurable (SM in SMart) commitments, exceed them (and Measure that!) and then get a big bonus. That makes sense right? If I set Achievable goals (the A in smArt goals), it should be possible to achieve and with some elbow grease, exceed them! The problem is that in a high performing organization, everybody hopes to exceed their goals. The reality is that companies have limited bonus pools. This and the fact that we do differentiated compensation, means that and not everybody can get an out sized bonus. What eventually ends up happening is that the managers sit together and see who had the biggest impact. However impact is as much or more about opportunity than hard work or skill. Think about the software engineers who have made the biggest impact – do you think Bill Gates or Mark Zukerberg were the smartest, most hardworking people of their times – far from it. They were one among thousands of smart and hardworking people – they were the people who had the opportunity and a ton of luck, made the impact and got the outsized bonus.
- Established “best practice”: You can set a specific, measurable, achievable sales quota at the start of the year and at the end of the year measure results and hand out a bonus, proportional to how much over the quota the salesperson came in. It is easy to give manufacturing a specific measurable production, quality or cost savings goal and then at the end of an arbitrary period of time ( a year) measure it and give people bonuses in direct proportion to revenue impact. If this works so well with sales and marketing, it must work well with software engineers right? Wrong! In the 70’s and 80’s software projects were managed like sales and manufacturing projects. Goals were set, plans were made and military like execution began – that failed miserably. It turned out that software development is CHAOTIC! So much so that the software industry ditched waterfall and embraced the chaos but rather than call the process CHAOS named it agile.
So what should we do?
- Replace Commitments with Visions or Epics: Do not pretend that you can set explicit commitments at the start of the year that will not change through the year. Work out your product vision, your scrum epics, whatever it is that you use to rally the troops, divvy up tasks and let the team go. Good responsible employees will do what they need to do to get the job done. Peer pressure and stand up meetings are really all that is needed to hold most reasonable people accountable. If you find people not meeting their commitments, pull them up, find out what is wrong and if necessary, have the hard manager-employee conversation. If they repeatedly do not meet commitments, let them go – they are not the right fit.
- Simplify Compensation: Do away with bonuses! Compensate everybody fairly and according to market value. Save yourself as a manager the awkward conversations around why they got only an X% bonus. Stop lying to employees that they are solely responsible for exceeding expectations. I don’t think bonuses are effective motivators – the reality is that most people do not walk around everyday mapping every task they do to the bonus that will be credited to their account several months down the line. And no, this is not socialism! Socialist countries could not fire their citizens – a company can. Moreover, a combination of people genuinely enjoying their work, the peer pressure of not letting their peers and their boss down and ultimately, the fear of holding onto their jobs is enough motivation for most people.
- Performance Evaluations at the Right Time: When planning a project, also plan a post-mortem. During the post mortem do not just look at the overall project but also individual performance. There is huge value in taking stock and looking for trends in an individuals strengths and weaknesses. However the best time to do that is at the end of a project and not at the end of the year. This makes sense because that is when memories are fresh. Also right after that project is likely coming up another project – the perfect opportunity to act on feedback and grow.
Nikhil's Musings 