It’s common in the web and app development industry for stakeholders to make a distinction between “designers” and “developers”. One of the things I’ve noted about this distinction is that it opens the door to antagonistic perceptions and even behaviors between the two camps. At a conference a few years ago, in the presence of developers expressing disparaging views regarding designers, I suggested that, “Designers are developers.” The deafening silence suggested I had to explain what I meant:
The more “design” and “developer” camps regard each other as part of the same effort to produce Great Things, the better things will work for everyone as well as the resulting Things. As part of this, the distinction between designers and developers needs to be toned down so communication between those engaging in these facets of product development can improve.
Since then, I’ve come to believe that a big part of the problem has less to do with those placed into the two camps and rather a lot to do with the corporate structure around the process.
Mithat’s Maxim #294: “People eventually do what they are rewarded for doing.”
As corporations increasingly embrace metrics-oriented performance evaluation, the pressure on those subject to them to produce the desired metric increases. Supporting this is a clear delineation of “my” versus “your” responsibilities. The consequences of this on the relationship between the “my” and “your” camps in a project should be pretty obvious.
Quite a long time ago, I read a study that found an organization’s productivity is maximized when there is perceived competition from outside the organization but competition within an organization is minimized. Assuming this is still the case, the consequences of creating a structure that effectively pits different aspects of the same team against each other on the overall product development process should be equally obvious.
If you want to do Great Things, let go of metrics-based management.