Every so often I come across some post on social media by someone in tech, be it a QA Engineer, a UI Designer, a UX Designer, a Frontend Engineer, a Backend Engineer, a DevOps Engineer, a Project Manager or really just about any role in tech. The post will usually contain some sort of graphic that depicts a stark contrast between when things go right with their job and when things go wrong. More specifically, they usually depict in some way how people in that role only get blamed when things go wrong, but are rarely recognised when things go well. A designer is not praised when they make beautiful designs that make sense, but they are in the first line of fire when the users get confused. QA engineers receive little or no praise when a release goes smoothly, but when things go south it's all their fault.
If you ever see one of these posts, it is worth it to have a look at the comments. Usually the post along with its commenters will try to make the point that their role is overlooked - they are the unsung heroes of the software development world. Apart from it being impossible that everyone is right, this points to something I consider to be a bigger problem. The problem is a major misunderstanding about how software is developed, specifically how web based software is developed. So, who are the unsung heroes of software? Obviously QA engineers who ensure quality and consistency…
Or maybe it's actually UX designer who painstakingly research and development software to ensure people have as smooth and as natural an experience as possible using the software. Then again maybe it's the software developers who actually write the software and turn ideas into reality. But what about the project managers who ensure that what is built is built on time and in scope? The problem is that tech roles are disproportionately siloed from each other which has allowed many different people in many different roles to think that they are the heroes. But here's the spoiler, with some exceptions that I will touch on soon, there are no heroes in software development. A UX Designer can make the most logical and sensible wireframes with a flawless user flow: all great, but not very pretty. A UI Designer can make the most beautiful designs: wonderful, but they are just fancy pictures. Developers can build amazing things, but their ideas can often fall completely flat in a maze of messy UI and UX. QA Engineer are absolutely amazing at picking up hidden bugs and faulty code, but they wouldn't have much to do without code to work on. Even going as far as tech CEOs: they can run amazing companies, but wouldn't have a product without the teams that builds it.
The fact that we, in tech, can so quickly silo ourselves off has lead to software teams that are always working against the grain. When a specific roles sees itself as the critical and indispensable role, it creates several major problems in your process. Timelines are messed with, vision and collaboration is lost and most tragically, antagonism is fostered in your team. Designers who think that their designs are the product and the key to the entirety of a build, will naturally be antagonistic to push back on their designs. Developers who think along similar lines are antagonistic to those who find issues with the things they've built. This antagonism is in many ways the root of the other two problems and many more. When these roles in tech become antagonistic to one another, they stop trying to collaborate and instead try to control and protect.
Now, the point I am pushing to is not to say that any of these roles are not important. Quite the opposite. What I am trying to say is that none of these roles are fully stand-alone. Of course you will get the exceptions; developers that have an eye for design, designers that can code or who are good at managing projects. Some projects are, of course, small enough to not need such a big team with so many processes. The point however, I'm general terms, is that successful software requires all these roles to work together. This working together then needs to be more than to mean “on the same project”. There needs to be real collaboration between teams. Developers need to trust that designers have put real thought and effort into the designs of an application. Designers in turn need to trust developers judgement when they see issues with designs when they consider how to build it out. QA Engineers need to be able to trust that developers are not trying to trick them to sneak bugs into production. Of course there are exceptions: some designer couldn't give a damn about the practicality of their design as long as it's pretty, some developers are lazy and have no desire to understand the vision of a designer, some QA Engineers really do approach QA like witch hunters trying to catch the sneaky developers out.
However, there are many in the software field in all these roles that have a genuine passion for making amazing things that can impact people. When those in these roles realise that they need each other - when they start to trust each other and depend on each other - they can truly build amazing software. This is where the hard truth comes in. Almost a majority of software teams think that they practice agile when in fact they practice mini-waterfall. The point of agile methodology is to tackle the building of software in vertical slices: integrating design, development, QA and everything into small cycles so that a product can iterate. This means development and design should be collaborating together to meet a requirement. It means that at the end of the sprint you won't have a working product but a working feature. How most companies that practice “agile” work is not like this. Most often these companies sprints in offset cycles where designers complete the designs and then the developer must build them out in the next. There might be varying degrees of collaboration, but at the end of the day the teams are siloed.
Now good software can be built like this, it's not impossible. Good teams can find ways to collaborate and adapt. Sometimes this process is the most pragmatic and visible. The problem I am pointing out is that this process confusion often stems out of the same antagonism I have been speaking about. Designers want to have their designs completed because they don't trust the developers to have valuable or useful input into the design process. Developers don't want to collaborate with designers because that would require extra thought and potential reworking of what they deem to be completed features. Managers don't help this problem because they are often so disconnected from the actual groundwork of building software that they just do things the way they have always been done.
At the end of the day we are all building software for someone. Whether that be a company or the general public or some private niche. When it comes down to it we all want to be the heroes who did it and in so doing quality and collaboration are caught in the crossfire are caught in the crossfire. If you don't believe my thesis, go and look at companies like 37Signals and you will be amazed at what can be done when trust and collaboration are baked into your process. I am not poking at anyone in particular, just giving some thoughts from my experience in the industry. The best software is built is built by amazing heroes but by good teams. Let's stop trying to be the unsung heroes and start becoming praiseworthy teams.