How programmers get disqualified from doing everything else
Being able to program is one of the few skills that can make you be seen as less than what you are.
I have been a product manager, project manager, SCRUM master and product owner, usability and requirements engineer and plenty of other things. I can interview users and design user interfaces, I can lead and coach teams, manage deadlines and set up projects. I’ve done all those things, and I’ve done them well.
But as soon as I mention that I write code, I’m a developer. Full stop. Now, a project manager has to be assigned to keep me on track. Others will write requirements specifications that I have to give estimates on. I don’t talk to users, and I have to give periodic updates on my progress.
It’s a very curious phenomenon that I’ve observed more than once, in many settings and organizations, and not just with me. It has gone to the point that I’ve actively avoided writing code (or pretended to not write code) in some projects, because I want the user or customer to trust me to (for example) handle the planning and requirements. As soon as I write code though, I become “the developer” on the team. And then that’s all I’ll ever be.
At the same time, however, dedicated project managers and product managers heavily gravitate towards well-rounded software engineers, that can do more than just write code. They are extremely happy to work with engineers who can communicate well, can create architectures that work (not only on a technical level but also on a project/business level) and can anticipate usability scenarios. No wonder; these skills fill the blind spots in their own skill sets. In many projects, however, these dedicated roles merely add an extra layer of communication indirection, and well-rounded engineers would often be able to do their work better without them.
Initially, I thought the phenomenon was mainly related to age. If you’re relatively young and admit to being a programmer, then it is more easy for people to see you as the stereotypical Silicon Valley-inspired developer; the basement-dwelling, hoodie-wearing antisocial computer kid. But I’ve seen the same happen with older, experienced engineers as well.
These engineers have seen companies rise and fall, founded startups, they’ve worked on multiple layers in companies and in a lot of roles, and have a strong technical background which makes them so broadly useful. But put them next to another person (usually a person in a suit), send them to a customer, tell them that one of them has a strong technical background, and the others will automatically assume he is the “tech guy”. When it comes to strategy, planning and so forth, they’ll go to the suit. Even though the engineer might be much better suited to discuss these topics.
So why is this? Why is there such a strong need to assign a label to the tech guy, and disqualify him from participation in other areas?
It might come from the human need to compartmentalize. Ideally, everything in life has a single task and purpose, so you can say “that is a hammer, you use it to hit things”, and “this is a monitor, it displays things”. It makes things easy to understand and predictable. To be sure, that’s how we develop good software as well, just look at the Unix philosophy.
But humans are not like that of course. We are always-changing, ever-evolving utility machines. The more one knows, has seen or has been, the better and more well-rounded he will be for any given task. We do recognize this development in experience in a single role, but, strangely, not between roles.
I argue that being able to program should never disqualify you from doing more in projects. On the contrary; it might very well make you better at things than others who lack this skill. If you have the ability to relate strategic discussions directly to a concrete technical level, and step through it with the logical mind of a developer, then that is worth much more than empty talks from a suit. If you can discuss a user problem and immediately see the implications of all the possible solutions throughout the system, not necessarily because you build the system but because you can relate with the technical challenges from experience, you and the user can make better-informed decisions, on the spot.
In my ideal team, any member can do the work of any other member but merely chooses to specialize in what he likes best. Role changes are encouraged and continuous, lines of communication are optimized and the set of roles is evaluated often. Such an ideal is not fully realistic in specialized professions, but an ideal is usually not something that is achieved, but rather something that we strive towards.
That’s why I think that every developer should strive to become a well-rounded engineer, that is able to do more than just write code and can contribute on multiple levels. And for that to work, it is important that engineers are stimulated, not discouraged, from being more than a developer.
