I was reminded this week of the common misconception that good developers are only interested in hardcore engineering and not in the delivery of business value. The additional assertion was made that in ‘the current climate’ that there is depressed demand for the hardcore engineers as business demands are more biased towards the technically mundane solutions that solve particular business requirements that, to most, are not exciting or technically interesting. I thought for a while and considered the developers that I have worked with in the last year and could not think of a single one that was more interested in the technology than the delivery.
So you have to wonder where this negative perception about software engineering comes from and, to me, it is the friction between engineering (development) and delivery (project management); putting aside the relationship between both of these groups and the business as neither group can claim the high ground. The reason for a lot of this friction is the lack of a technical person that is responsible for the technical team, resulting in a management gap between developers and projects managers. There are a lot of reasons for this gap and in many cases it is caused by the behaviour of developers themselves. Developers, it is generally agreed, don’t like to be managed – they feel that they need to be ‘lead’. So we have roles such as ‘technical lead’, ‘dev lead’, or ‘team lead’ as a label to attach to the senior developer in the team that is somewhat responsible but, because it is a toothless role without influence and the ‘lead’ still needs to code 100% of the time, cannot be considered a management position. So ‘technical leadership’ refers more towards technical though leadership, understanding and mastery of the latest technologies and engineering techniques, as well as respect of coding ability by the technical team and the broader community. It does not refer to the general middle management ability to lead and manage people.
The biggest reason why nobody is filling that gap is that there is simply no career path – the recognition, demand and remuneration for a technical manager is extremely low and is, therefore, matched by the complete lack of interest. A few years ago the ‘architect’ role seemed destined to fulfil this need (particularly the solution architect), being a person who was able to manage people, understand the business and code (to a degree). But the architect role was quickly abused and, quite rightly, rejected by developers as generally useless people began to hijack the term. The project management and business side has also played a role in discouraging emerging managers, by failing to indentify potential managers, implementing ‘flat’ structures for some or other good and generally failing to understand that it takes a geek to manage a geek.
A few weeks ago I was in a large room with my colleagues and while looking around the room I noticed, with shock, that the average age for us ‘Microsoft Developers’ (a brush that we are tarred with) was actually quite high. It would stand to reason that in that room where most people were above thirty years old that there was a lot of experience and ability in non-technical functions waiting to be harvested – instead the environment and market seems to prefer to keep technical people technical and a wealth of abilities is lost and left underdeveloped.
I don’t think that the solutions to this problem is easy. To begin with, developers need to become more manageable and accept that leadership goes beyond technical proficiency – at some point, regardless of how we deride them, TPS reports may be required. Likewise, senior management needs to understand that developers should be managed by technical people that can still code, and the relevant structures, environments, training, mentoring and processes need to be in place to encourage the development of technical people into competent managers that can still get their kicks out of coding.
Simon Munro
@simonmunro