Think of tech job roles and their descriptions as tidy boundary lines drawn around groups of related responsibilities. Picture them as perfect square boxes.
Now think of the people who fill those jobs (and yourself). Chances are that we don’t quite line up with the boxes of the roles we find ourselves in. Our skill sets have gaps and protrusions; we have some weaknesses to improve upon, but also add value with some “extras.” (This is normal. It’s why we’re able to apply for and get jobs for which we don’t meet all of the requirements.)
We’re jigsaw puzzle pieces.
Companies think they need squares. Many tasks and responsibilities are non-negotiable, especially when building quality software. Luckily for us, when working in cross-functional teams, the puzzle scales. The box of requirements broadens, too, but we have more puzzle pieces to cover it. It matters less who covers an area as long as someone does.
In reality, it’s not that rigid. We’re not so defined, and our areas of expertise don’t stop where our teammates’ begin. There are areas of overlap. Darker pinks and reds where there are gaps or protrusions in the illustration above. Blobbier shapes. Splats and splotches. We look more like this.
After a conversation between us, software engineer Nishiki Liu mused on the software spectrum of roles and responsibilities, listing them out and using a more linear metaphor.
What happens when someone’s core skills sit right in the middle of a cut? What happens when someone is excellent at both ends of the spectrum? What happens when someone wants to pursue an unorthodox skill set at work? How can companies start supporting employees that don’t fit the traditional mold?
Modern agile and self-organising teams make this support more possible. Having multiple people work on one story or task blurs the lines as they move it from idea to design to code to live product (and around and back again). Pair programming makes it even harder to discern who does what. Our blobby skill sets become melded together in a bigger, complementary blob. The boxes become a distant memory.
However, software companies tend to be structured such that individual contributors work within teams across two axes — cross-functionally and within their disciplines — which again complicates things. What I owe the engineers and product manager on my scrum team has no resemblance to what I owe my fellow designers. Further complications to the model arise from company size (and therefore departmental and individual specialisms), seniority/skill levels, and perhaps most importantly when trying to overlay someone as a square over top of a box: what are they even interested in doing? How much control do they have over the expansion and evolution of their own blob?
Nishiki doesn’t know the answers to his questions. Many managers and companies haven’t even asked themselves these questions. The boxes need filling and anyone who doesn’t fit is a problem. Until those “square” companies find answers and embrace the blob, otherwise valuable employees will continue to be unsupported, underutilised, and unfulfilled.