Having worked for a number of companies who believe the only way to show their appreciation for hard working developers is to give them more responsibility, I am a firm believer in doing the exact opposite. Companies move successful developers into other areas of their business, often into people management, and take away what makes the developer good at their job, or at the very least dilute their skills by asking them to focus on people rather than code. But there’s a reason your developer is good at what they do. Most developers are not ‘people people’, they are software people and for very good reasons.
If the software development team is writing the core product or system the business is using day-to-day, moving those developers away from developing will have a significant impact on productivity and quality. Even promoting a developer to an architect, for the purposes of paying them more, is often wrong. Software architects are not the same as building architects, they still need to code and code regularly. Obviously there are exceptions to the rule and a developer may want to make a career change. If they want to move to something very different, let them. If they want more responsibility, make it over the design and or make them the team or project technical lead, but make sure someone else does the people management of the team.
Perhaps some companies feel the need to justify the pay rise on offer, giving the developer more diverse responsibilities in order to do so, but why would you move someone from a job they excel at into a job they’ll struggle with just to pay them more money? Tech firms need to understand that their software developers are at least as important as their people managers, if not more so, and recognise the importance of technical excellence. The solution as a business owner is to keep talking to your developers, make sure they’re doing what is best for them, and your business, and regularly increase their pay in line with everyone else in the company. A good developer is a valuable asset, so reward them by letting them shine in their role. Listen to what they have to say and let them manage code, not people.
Ideas: Paul Grenyer
Words: Lauren Gwynn