I meet a lot of people in IT these days who seem to have a very narrow field of expertise. We kid ourselves that IT has now become so complex that we need to specialize in roles so narrow that one can only hope that the world of work will always value us, just for our ability to program in JavaScript with jQuery. It is a symptom of the very transient, role-based nature of any employment nowadays.

Times have changed. In the first half of the twentieth century, the common attitude in the West was that you worked for one company for all or most of your working life. This had ramifications both for employer and employee. The employer had a responsibility to nurture the potential and skills of the employee, and the employee was expected to take a broad view in understanding how the business worked. For any aspiring manager, it was essential to get a broad 'worms-eye-view' of what it was like to work within a range of teams, and a diversity of jobs.

This meant that employees were required to change jobs quite often, within the company, to give them a better understanding of the business processes and to give them the opportunity of experiencing different work environments and different types of team. For a while, you might work in Sales, then a spell in Manufacturing, then on to Finance. It was a huge game of Musical Chairs.

Even within the IT activities, people changed jobs often. I experienced Unix workstations, CAE, CAD, Helpdesk, Development, Database administration, production support, network architecture and a range of other tasks. I loved it. The most immediate impact of this practice was to see how all the IT processes were supposed to work together, but sometimes didn't. One developed a terrific sense of how effective communication of ideas and requirements could rapidly get things done. It also demolished the strange tribal barriers that so often get thrown up within IT. We were all one tribe, because we'd all been initiated in all the common IT roles.

Even the most elaborate team-based development methodology won't compensate for the blinkered attitudes and tribal cultures that come from over-specialization. If, for example, you've experienced being an Ops guy and understand the pain points, you are going to more likely to understand DevOps processes when you are developing applications. When you've worked on the requirements for compliance in business IT, you'll never sneer at the work of the people who ensure that IT practices conform with industry standards. If you've supported end-users, you'll quickly recognize bad application design. There is a lot to be said for diverse experience in IT.

Phil Factor.