Responsible Seniority

Posted by Phil on December 28, 2017

This article will sound pretty negative and pessimistic initially. Bear with me - that's not where I end up going.

I expect there's a degree of confirmation bias given I'm working within the industry, but I can think of few professions that demonstrate as much elitism or self-righteousness as software development. I expect all disciplines suffer from it in some way or other: law, medicine, professional sports... But I don't feel that any are quite so publicly prominent as software. 

The thing that started my examining our industry's behavioural norms was a series of tweets where senior developers have demonstrated such astounding tone-deafness, arrogance or outright abusiveness to juniors that I'm left wondering what it is about our industry that fosters these attitudes and what our collective responsibilities are as participants in this culture to address them. Once I started noticing the tone or content of comments, it seemed that there were more instances in recent weeks than I remembered seeing previously. Perhaps it's just that Christmas and New Year is a stressful time and people are more tired and less guarded in their language than usual.

It would be easy to take an inward look at the software development industry and chalk it up as an irredeemable trash fire, given its well-documented cases of sexism, unethical business conduct and discrimination. News articles, personal stories and third hand accounts paint some pretty grim pictures, but my world view - despite my well-curated cynical and bitter persona - is incurably optimistic and I see huge effort being invested to make it better. So with the recent focus on poor senior attitudes and even poorer junior experiences, I found myself wondering what it is that contributes to these imbalances and how our context-laden hierarchy structures reinforce unhealthy power dynamics. 

What is "senior"?

More and more, I find myself being less enthusiastic and invested in the concept of "senior", "intermediate" and "junior" when referring to developers or consultants. I touched on this subject last year when I paraphrased Randall Koutnik's concept of "implementer", "solver" and "finder". This diminishes the inherent "pecking order" inference and seeks to redefine what it is we expect from our different levels of technical and business cognisance. Yet even here I'm not sure it goes far enough.

The traditional role of career progression from graduate / junior level through to senior (and then presumably management) is as pervasive in Information Technology as it is anywhere else. The trick about the technology industry however is that the rate of change and the potential scope of things to learn is a horizon no ship can ever crest. You might become highly technically proficient, or broaden your skill base into other areas, but ultimately no person can attain that much knowledge, experience and applicable skill in their chosen disciplines such that they're able to say they've mastered all of them.

I say this quite deliberately because when everything else about software is stripped away, at the nucleus is people. People seek to make their tasks easier, more reliable, safer or more connected and software is the tool by which they can achieve that goal. Other people with the knowledge of how to build software are burdened with creating the solution to achieve the stated goals. The ways in which we communicate and interact with each other in the undertaking of that process determines everything from how successful the outcome is, to how we grow and develop as professionals.

There's a perception in software that the senior is the person who has refined their skills to a sharp point and can execute the most complex problems with an almost-surgical precision while demonstrating an acute knowledge of their company's business. The reality however is often far removed from that stereotype. I've been a senior developer in one form or another for probably half my working career and I'm abundantly aware that there are newcomers in my office who have a far better grasp of basic computing concepts that I just haven't been exposed to. Others in my office have been faced with some specific business problems their clients presented that have meant they've gained some deep understanding of particular software frameworks and design approaches that I'll never have time to match. However what I lack in technical skill, I make up for in other areas. For example, my breadth of knowledge means I can present a range of possible solutions across a number of different technologies that might not be immediately obvious to others. I'm a naturally people-focussed person who understands the non-technical, user experience and team leadership language and behaviours so that I can help lift peoples' understanding without technical jargon or condescending phrasing.

The key thing about more seniority isn't the technical skill or years of experience; it's the generativity of the person in question and their ability to rally and develop the people around them. A manager can assign a task to Bob The Grey, a wizard-like 20 year veteran of the company who knows every nuance of the software and its purpose, but if everyone else in the team hates his patronising tone and lack of leadership, his only qualification as a senior is that he's been around longer.

My view is that as people become more senior in their role, they necessarily become less focussed on code, and more focussed on teaching. I wrote about this three years ago. This doesn't mean a senior has to divorce themselves from from the product or code they enjoy so much, merely that their view of it needs to change such that they are the curator of the code they want to see in the product; the decision-maker who is able to anticipate problems autonomously: the "Finder" of solutions.

The measure of juniors or seniors isn't their technical skill or years of experience. It's not about how "safe" you expect that Big Client to be in their hands. It's what they bring to the table in empathy, patience and how well they raise the bar for everyone else that counts. Seniority largely depends on context when viewed from the perspective of technical expertise (e.g. I'm a senior .Net developer but put me in a Python business and I'm an immediate junior). Your ability to handle the people situations is the differentiator.

Finally, if you're a junior or intermediate developer and you feel like you don't matter, you aren't cut out / capable for software development or you aren't coping, send me a message! I'm willing to bet the problem isn't you and there will always be systemic factors that are contributing. Finding the right mentor and the key messages is absolutely crucial as you navigate this industry and I'm rewarded by seeing people succeed. Find me on Twitter or send me an email.


Photo Credits

unsplash-logoJoanna Kosinska

unsplash-logoHeidi Sandstrom.