I had an interaction on Twitter today which got me thinking – as Twitter discussions often do, because the amount of debate possible in 140-char limits leaves many things left over to think about. I think this blog post is mainly just to make the arguments that I couldn’t on Twitter. I’m not sure that’s a good enough reason but hey, it’s my blog.
The beginning of today’s conversation was this tweet I saw: “Dear developers: to have any sort of impact in this industry — managerial, or technical — you need to know how to people.”.
Now, in its defence, the tweet is true from at least two points of view. Firstly, the status quo argument: as things are, at present, you need to have influencing skills to get anywhere. That’s true, and it’s good advice if you want to get promotion. But it doesn’t really move us forward towards anything better: is that what we want the industry to look like? Is it the way to get the best results? Does it make us better developers, worse developers, or make no difference?
Secondly, of course it’s true that anyone needs a minimum level of people skills in order to – frankly – not be an arsehole to work with. Definitely. That’s a fairly low bar, admittedly, but some people still don’t reach it.
But in a broader sense, I think that it’s bad advice. Because it’s another example of trying to do everything.
Developers are supposed to have strong technical skills. They’re supposed to know how to code, how to test, how to architect, how to analyse a domain, how to work in a team, how to write good reusable APIs, and much more. They’re supposed to keep up to date with changing technologies, new languages, and changing businesses that use the technologies. They’re supposed to know databases, frameworks and build tools, all of which change constantly. And most importantly, they need to make good judgement calls on which of many different options is most likely to be robust, flexible and sustainable in an unpredictable future. This is a high-skill profession. It’s actually quite easy to learn a programming language and get coding, but to write good-quality enterprise software is hard.
All these skills can be learned, and are learned. Partly on the job, often in the developer’s own time, and continually. And yes, people skills can be learned too. But there are only 24 hours in a day, only 365 days in a year. The more skills a developer has to learn, the less expert they can become.
This sounds like a bit of a straw man – after all, asking developers to learn people skills isn’t a huge ask – maybe it takes 10% of their learning time. So they’re a bit less up-to-date, a bit less expert in some technology or other – will it really make a difference to the outcome of the project? Isn’t the benefit from the improved communication worth it? It seems like the answer should be yes. But…
The catch is this. Once we say that we expect developers to have people skills to sell their technical arguments – which is totally reasonable – we then structure the organisation so that the best presented argument wins. It is very easy to then say (in fact, hard not to say) that the developer who explains their idea best is the best technologist. They have impact and influence. The onus is no longer on anyone else in the organisation to understand the technical issues: the best solution is the one that non-experts understand, and the best technologist is the one who presented it.
If you promote based on ability to communicate ideas, you turn your organisation into a people skills competition1. Then the people who make technical decisions won’t be the ones who spent 10% of their time to learn people skills. They’ll be the ones who spent 90% of their time to learn people skills. And that’s not enough time left to spend learning the technology.
It would be great to have team members who can do everything, who have excellent technical skills and excellent people skills. Just like it would be great to deliver every project idea and great to include every feature. Sadly, that’s not how the world works. We have to choose: to prioritise and specialise. And if we say that the best-communicated argument wins, we prioritise people skills over technical ability and we will get bad software.
Which, I would argue, is pretty much the case now.
1 Caveat: people managers should absolutely be promoted based on people skills. But they should not have the final say on technical issues unless they also have very strong technical skills.